CENTRAL  CIRCULATION  BOOKSTACKS 

The  person  charging  this  material  is  re- 
sponsible for  its  renewal  or  its  return  to 
the  library  from  which  it  was  borrowed 
on  or  before  the  Latest  Date  stamped 
below.  You  may  be  charged  a  minimum 
fee  of  $75.00  for  each  lost  book. 

Th«f»,   mutilation,  and   underlining   of  books  are   reasons 
for  disciplinary  action  and  may   result  in  dismissal   from 
the  University. 
TO  RENEW  CALL  TELEPHONE  CENTER,  333-8400 

UNIVERSITY   OF    ILLINOIS    LIBRARY    AT    URBANA-CHAMPAIGN 


JAN  2  8  1996 
FEB  1 2  1997 
AUG  2  4  2006 


When  renewing  by  phone,  write  new  due  date  below 
previous  due  date.  L162 


r 


UIUCDCS-R-77-861 


rh  ^u 


UILU-ENG  77  1713 


H 


is 


A  PASCAL  COMPILER 

"by 
Yao-Ching  Stephen  Chen 


April  1977 


DEPARTMENT  OF  COMPUTER  SCIENCE 
UNIVERSITY  OF  ILLINOIS  AT  URBANA-CHAMPAIGN 


URBANA,  ILLINOIS 


The  Library  of  the 


JUN  2  4  1977 


isity  or  Illinois 


A  PASCAL  COMPILER 


by 

YAO-CHING  STEPHEN  CHEN 

B.S.,  National  Taiwan  University*  1971 


THESIS 

Submitted  in  partial  fulfillment  of  the  requirements 

for  the  degree  of   Faster  of  Science  in  Computer  Science 

in  the  Graduate  College  of  the 

University  of  Illinois  at  Urbana -Champai gn*  1977 


Urbana/  1 1  I i  noi  s 


Digitized  by  the  Internet  Archive 

in  2013 


http://archive.org/details/pascalcompiler861chen 


1 1  1 


ACKNOWLEDGEMENTS 


I  wish  to  express  my  gratitude  to  professor  Thomas  T.  Chen  for 
his  continued  advice  and  support  throughout  the  development  of  this 
project.  Thanks  also  go  to  A.  B.  Baskin  and  Douglas  W.  Jones  for 
their  many  helpful  suggestions  during  the  implementation  phase  of 
this  pro j  ect . 


1  V 


TABLE     OF     CONTENTS 

Page 

1.  INTRODUCTION  1 

1.1.   THF  SYSTEM  ENVIRONMENT  2 

1.?.   THF  DESI6N  OF  THIS  COMPILER 2 

1.2.1.  LANGUAGE  USED  FOR  ENCODING  THE  COMPILER     .   .  3 

1.2.2.  COMPILER  TARGET  LANGUAGE    4 

1.2.3.  THE  CHOICE  OF  A  PARSING  ALGORITHM     ....  4 

1.2.4.  ENCODING  THE  COMPILER    5 

1.2.4.1.  SYNTAX  ANALYZER  AND  SCANNER  5 

1.2.4.2.  SEMANTIC  ANALYZER  AND  CODE  GENERATION     .   .  6 

1.2.4.3.  RUNTIME  ROUTINES     6 

2.  MSP  PASCAL  GRAMMAR 7 

2.1.  MIXED  STRATEGY  PRECEDENCE  7 

2.1.1.  MSP  AND  STACKING-DECISION  PREDICATE  ....  6 

2.1.2.  MSP  AND  PRODUCTION  SELECTION   9 

2.2.  THE  MSP  PASCAL  GRAMMAR 10 

2.3.  DIFFERENCES  IN  SYNTAX  BETWEEN  THE  MSP  PASCAL 
GRAMMAR  AND  THE  STANDARD  PASCAL  GRAMMAR   ...  11 

2.3.1.  THE  EMPTY  STATEMENT 11 

2.3.2.  FILE  VARIABLE  AND  POINTER  VARIABLE   ....  13 

^.   THE  SCANNER  AND  THE  SYNTAX  ANALYZER 15 

3.1.  THE  SCANNER  OF  THIS  COMPILING  SYSTEM   ....  15 

3.1.1.  THE  PROCEDURES  READ  AND  WRITE 16 

3.1.2.  THE  SCANNER  AND  READ,  WRITE  PROCEDURES  ...  16 

3.2.  SYNTAX  ANALYSIS 17 

4.   SYMBOL  TABLE  MANAGEMENT    19 


4.1.  STRUCTURE  OF  AN  ENTRY  IN  THE  SYMBOL  TABLE 

4.2.  REPRESENTING  STRUCTURE  IN  THE  SYMBOL  TABLE 


19 
21 


RUNTIME  STORAGE  MANAGEMENT   25 

5.1.  STACK-BASED  STORAGE  MANAGEMENT    25 

5.2.  HEAP  STORAGE  ALLOCATION 26 

5.3.  STATIC  STORAGE  MANAGEMENT   -   AN  EXTENSION   .   .  27 

5. A.   DATA  STRUCTURES 27 

5.4.1.   STORAGE  FOR  ELEMENTARY  DATA  TYPES    ....  27 

5. A. 2.   ARRAY 28 

5. A. 3.   RECORD 28 

5. A. A.   FILE 28 

5. A. 5.   SET  TYPES 29 

5. A. 6.   PACKED  STRUCTURE  TYPE 29 

5. A. 7.   ACTUAL  -  FORMAL  PARAMETERS  .    .  30 

SEMANTIC  TRANSLATION   32 

6.1.  THE  SEMANTIC  ANALYZER  AND  CODE  GENERATION     .   .  32 

6.2.  CODE  GENERATION  ROUTINES .  3A 

6.2.1.  REGISTER  ALLOCATION  ROUTINES   ......  3A 

6.2.2.  THE  BI NOP  ROUTINE    3A 

6.3.  AN  EXAMPLE  FOR  CODE  GENERATION 35 

6. A.   REMARKS  ON  GOTO  STATEMENT 36 

6.5.   ERROR  RECOVERY 37 

6.5.1.  RECOVERING  FROM  SEMANTIC  ERRORS   37 

6.5.2.  RECOVERING  FROM  SYNTACTIC  ERRORS  37 


7.   EXTENSIONS  TO  THE  MODCOMP  PASCAL  SYSTEM 


39 


7.1.  COMMON  VARIABLE 39 

7.1.1.  SPECIFICATIONS  FOR  THE  COMMON  VARIABLE         .  AO 

7.1.2.  AN  ALTERNATIVE  APPROACH  FOR 

VARIABLE  INITIALIZATION  AD 

7.2.  EXTERNAL  PROCEDURES  A1 

7.2.1.  SYNTAX  FOR  EXTERNAL  PROCEDURES 

IN  MAIN  PROGRAM A2 

7.2.2.  PREPARING  ASSEMBLY  PROGRAM  AS 

EXTERNAL  PROCEDURE     A2 

7.3.  FORWARD  PROCEDURES   A2 

7. A.   FILE  TYPES A3 

7.5.   READ/WRITE  PROCEDURES  AND  RANDOM  ACCESS  FILES   .  A5 

SUMMARY     .       A6 


VI 


LIST  OF 


APPENDIX 
APPFNDIX 
APPFNDIX 
APPENDIX 

APPENDIX 

APPFNDIX 
APPENDIX 


REFERENCES A8 

A  -  THE  PASCAL  BNF  GRAMMAR 50 

B  -  STATISTICS  FOR  SYNTAX  TABLES    57 

C  -  SPECIFICATIONS  FOR  THE  SEMANTIC  STACK  .  .  58 
D  -  PASCAL  RUNTIME  PACKAGE  AND 

EXTERNAL  PROCEDURES    59 

E  -  MACROS  FOR  PREPARING  ASSEMBLY  SUBROUTINE 

AS  EXTERNAL  PROCEDURE  63 

F  -  REGISTER  ALLOCATION    65 

G  -  SUBROUTINE  LINKAGE  67 


Page    1 


1.   INTRODUCTION 

*  compiler  for  the  PASCAL  [4/5/21]  programming  language  has 
been  implemented  on  the  MODCOMP  IV  [15]  computer  system.  The 
compi  ler/  which  is  encoded  in  FORTRAN/  is  one  pass  and  generates 
reentrant  assembly  code.  Its  syntax  parsing  algorithm  is  based  on 
Mixed  Strateay  Precedence (MSP)  [10]/  and  the  MSP  PASCAL  grammar 
[Chapter  2]  used  in  this  compiler  is  listed  in  Appendix  A. 

The  FORTRAN  and  BASIC  currently  supplied  by  MODCOMP  are  not 
well  suited  for  system  software  development.  The  principal  goal  of 
this  project  is  to  implement  a  powerful  language  which  may  be 
compiled  into  efficient  machine  code  and  used  for  system  software 
and  data  base  management.  It  is  also  desired  that  the  project  be 
completed  within  a  reasonable  amount  of  time.  After  careful 
analysis/  PASCAL/  which  combines  a  rich  data  type  structure  with 
strono  type  checking/  was  selected  as  the  language  to  be 
i  mp  lemented . 


PASCAL/  designed  by  Dr.  Niklaus  Wirth/  is  an  ALGOL-like  [12/14] 
programming  language  with  extensive  data  structure  facilities.  The 
original  language  definition  is  in  "The  Programming  Language  PASCAL" 
[21]/  and  the  concise  definition  of  an  updated  standard  PASCAL  can 
be  found  in  the  Revised  Report  in  the  "PASCAL  User  Manual  and 
Report"  [5].  Since  detailed  information  regarding  PASCAL  is  readily 
available  in  the  literature/  this  paper  will  only  concentrate  on  the 
local  implementation. 
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1.1.   THE  SYSTEM  ENVIRONMENT 


The  MODCOMP  IV  is  a  medi um-to-l arge/  mu I t iprogr ammable /  paged 
memory/  qeneral  purpose  computer/  with  a  maximum  central  memory 
capacity  of  one  million  8  bit  bytes.  A  disk  operating  system/  MAX 
IV/  is  provided  to  control  the  MODCOMP  IV  paged  memory  system/  the 
register  context  hardware  and  the  priority  task  execution 
[15/16,173. 

Due  to  local  system  constraints/  the  size  of  the  compiler  is 
limited  to  a  maximum  of  27/648  (Hex  6C00)  16  bit  words.  This  has 
necessitated  the  tight  packing  of  many  tables/  and  the  excluding  of 
the  implementation  of  some  language  features.  However/  these 
limitations  may  be  lifted  when  more  core  memory  becomes  available  on 
the  local  system . 

1.?.   THE  DESIGN  OF  THIS  COMPILER 


Basically/  this  implementation  of  a  PASCAL  compiler  is  a 
one-pass  processor  which  generates  assembly  language  as  its  object 
code.  The  execution  of  a  PASCAL  program  requires  the  service  of  the 
PASCAL  compiler/  assembler  and  link-loader  in  that  order.  The 
assembly  code  generated  by  the  compiler  is  system  compatible  and  can 
be  stored/  examined  and  edited  by  system  utilities. 
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/ 
1.2.1.   LANGUAGE  USED  FOR  ENCODING  THE  COMPILER 

It  was  decided  in  the  early  stages  of  development  that  a  hiqh 
level  lanquaqe  should  be  used  to  encode  the  compiler.  The  use  of 
the  assembly  lanquage  could  be  justified  because  of  efficiency. 
However  the  current  trend  in  programming  is  toward  using  higher 
level  languages*  and  regarding  programming  as  an  engineering 
discipline.  Its  reasons  are  obvious:  easier  programming*  less 
effort  required  in  debugging  and  modification*  and  less  cost. 

FORTRAN  certainly  is  not  an  ideal  compiler  writing  language. 
FORTRAN  is  not  flexible  enough  in  its  control  structures*  especially 
in  its  lack  of  recursion.  In  dealing  with  data  structures*  FORTRAN 
provides  very  little  support  in  maintaining  such  well-defined 
structures  as  stacks  and  binary  trees.  Given  the  conventional 
FORTRAN  data  structures*  strings*  stacks  and  binary  trees  have  to  be 
simulated  by  the  use  of  vectors  and  appropriate  routines  to  support 
operations  on  them.  However*  FORTRAN  was  used  for  the  encoding  of 
the  PASCAL  compiler  because  it  was  the  best  available  language  on 
the  local  system . 


It  would  be  possible  to  have  a  boot-strap  PASCAL  compiler 
written  in  PASCAL  on  another  system  which  already  has  a  PASCAL 
compiler*  and  the  boot-strapping  compiler  could  generate  the  target 
machine  executable  code.  Indeed*  this  is  an  elegant  method  for 
writing  a  compiler.  It  was  not  adopted  here  for  two  main  reasons: 
First*    writing    a    boot-strapping   compiler   itself   requires   a 
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tremendous   demand   on   the  resources   of  the  other  computer  system 

which    are    not   readily  available.   Secondly*   the   MSP   parsing 

aloorithm   C 1 03   is   based  on   many  syntax  tables  [Appendix  BD*  and 

there   exist   no   adequate  features   in   PASCAL  to  initialize  those 

tables. 

1.2.2.  COMPILER  TARGET  LANGUAGE 

The  compiler  can  generate  either  assembly  or  machine  code.  In 
order  to  ease  the  burden  of  debugging  the  compiler*  the  assembly 
lanouage  was  selected  as  the  target  language.  Moreover*  this 
approach  takes  advantage  of  utility  routines  in  the  assembler*  thus 
reducing  the  size  of  basic  compiler.  For  example*  the  memory 
allocation  of  PASCAL  can  be  handled  by  pseudo  assembly  instructions. 
Of  equal  significance  is  the  availability  of  macro  assembly  language 
features  for  code  generation. 

1.2.3.  THE  CHOICE  OF  A  PARSING  ALGORITHM 


A  formal  parsing  algorithm  is  used  because  of  the  availability 
of  many  we  I  I -deve loped  Translator-Writing-Systems  (TWS)  which  are 
very  powerful  tools  for  compiler  writing.  The  Mixed- 
Strategy-Precedence  (MSP)  parsing  algorithm  was  selected  because  of 
the  existence  of  an  MSP  grammar  analyzer  C 1 03  on  the  IBM/360. 
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1.2.4.   ENCODING  THE  COMPILER 

A  decision  must  be  made  about  the  number  of  passes  for  the 
compiling  process  before  encoding  the  compiler.  A  one-pass  approach 
was  selected  mainly  in  the  interest  of  the  compilation  speed.  This 
section  serves  as  an  introduction  to  the  encoding  of  the  compiler/" 
detailed  discussions  are  given  in  later  chapters. 

1.2.4.1.   SYNTAX  ANALYZER  AND  SCANNER 

The  first  step  in  encodino  the  PASCAL  compiler  was  to  manually 
develop  a  grammar  [Appendix  A3  in  Bac kus-Naur-Fo rm[6NF3  .  Based  on 
this  grammar/  a  grammar  analyzer/  which  is  part  of  the  TWS  designed 
by  McKeeman  [103/  was  used  to  produce  the  syntax  tables  [Appendix  B3 
for  the  MSP  parsing  algorithm.  The  grammar  analyzer  was  also 
designed  to  check  whether  the  BNF  grammar  for  PASCAL  was  MSP  of 
degree  (2/l;l/1)  parsable.  Although  the  grammar  analyzer  was  run 
under  the  IBM  OS/360/  all  of  the  other  tasks  in  implementing  this 
compiler  were  done  on  the  local  system. 


The  next  step  was  the  encoding  of  the  MSP  syntax  recognizer  in 
FORTRAN.  This  syntax  recognizer  utilized  the  tables  [Appendix  B3 
produced  by  the  grammar  analyzer;  however/  those  tables  had  to  be 
transformed  from  XPL  data  format  into  FORTRAN  data  statements  first 
(XPL  is  a  dialect  of  PL/I  and  is  part  of  the  TWS  C 1 0D  > .  The  scanner 
[Chapter  33  was  developed  next/  and  the  compiler  at  this  stage  could 
be  used  for  syntax  checkinn. 
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1.2. A. 2.   SEMANTIC  ANALYZER  AND  CODE  GENERATION 


Semantic  analysis  and  code  generation  constituted  the  major 
effort  of  writing  this  compiler.  The  semantic  analyzer  includes 
symbol  table  management  [Chapter  43/  runtime  storage  management 
[Chapter  5]  and  semantic  routines  [chapter  63  for  various  constructs 
in  PASCAL.  Since  this  was  to  be  a  one-pass  compiler*  code 
generation  was  mixed  with  semantic  analysis/  and  the  code  generation 
routines  [Chapter  <S3  were  called  by  semantic  routines. 

1.2.4.3.   RUNTIME  ROUTINES 


Before  a  PASCAL  prooram  is  ready  for  execution/  the  code 
aenerated  by  the  compiler  must  be  linked  with  the  PASCAL  runtime 
package.  The  runtime  routines  include  such  standard  procedures  as 
READ/  WRITE/  NEW/  etc.  [Appendix  D3.  Also  included  are  external 
procedures  for  individual  programs  [Appendix  03.  All  the  routines 
in  the  runtime  package  were  encoded  in  assembly  language  for 
achieving  better  efficiency/  although  most  of  them  could  be  encoded 
in  PASCAL. 
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2.   MSP  PASCAL  GRAMMAR 

A  BNF  qrammar  [Appendix  A]/  which  is  MSP  of  degree  (2#1;1/1) 
parsable/  was  developed  for  this  compiler.  It  will  be  called  the 
MSF  PASCAL  grammar  hereafter.  The  syntax  analysis  of  this 
implementation  was  based  directly  on  that  grammar*  and  the  syntax 
analyzer  is  able  to  parse  all  standard  PASCAL  statements.  The 
general  concept  of  MSP  and  the  problems  encountered  during 
generatinq  the  qrammar  are  discussed  in  this  chapter. 

2.1.   MIXED  STRATEGY  PRECEDENCE 


The  Mi xed-St rat egy-Precedence (MSP)  algorithm  used  in  this 
compiler  is  a  bottom-up  recognizer.  The  idea  of  precedence 
relations  in  a  grammar  was  first  introduded  by  Floyd  C2D/  while  the 
(1/2)(2/1)  precedence  extension  was  introduced  by  McKeeman  L9D .  The 
latter/  which  was  further  refined/  was  used  in  the  XPL  compiler 
writing  system  C103.  In  MSP/  as  with  most  of  other  bottom-up 
parsing  algorithms/  the  following  three  steps  are  iterated  until  the 
whole  program  is  reduced  to  the  goal  symbol  C33: 
1  .  Find  the  handle  x; 

2.  Kind  a  production  rule  U  ::=x;  and 

3.  Reduce  X  to  U/  and  create  one  branch  of  the  syntax  tree. 
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The  principal  advantage  of  the  MSP  algorithm  is  its  ability  to 
support  a  less-costly  sh i ft -reduce  parsable  class  of  grammars.  In 
other  words/  the  MSP  algorithm  uses  simple  and  small  tables  to  make 
as  many  decisions  as  possible/  but  extends  the  class  of  acceptable 
grammars  by  usinq  more  decisions  when  necessary.  As  is  further 
discussed  in  the  next  two  sections*  the  MSP  algorithm  applies  the 
precedence  relations  ( st ack i ng-dec i s i on  predicates)  to  locate  the 
richt  end  of  the  handle;  it  then  uses  context  checking  to  both 
locate  the  left  end  of  the  handle  and  select  the  correct  production 
rule  for  reduction.  Therefore/  a  grammar  is  called  MSP  of  degree 
(p/q;m/n)  C10]/  if/  for  that  grammar/  the  st acki ng-dec i s ion 
predicate  is  of  degree(p*q)  and  the  production  selection  function  is 
of  degree (m/n)  . 

2.1.1.   MSP  AND  STACKING-DECISION  PREDICATE 


The  stack inq-dec i s ion  predicate  of  degree(1*1)s  called  symbol 
pair  predicate/  may  be  efficiently  represented  by  a  two-dimensional 
boolean  array.  Although  a  symbol  pair  grammar  can  be  constructed 
for  many  languages/  considerable  manipulation  of  the  grammar  is 
usually  required  to  make  it  acceptable  to  the  algorithm;  and/  as  a 
result/  the  grammar  cannot  be  presented  to  the  user  as  a  reference 
to  the  language  C13.  By  using  another  symbol  in  the  stack/ 
predicates  of  degree(2/1)  accept  a  wider  class  of  grammars. 
However/  direct  representation  of  predicates  of  degree(2/1)  may 
require   an   unmanageably  large  table  (order  of  n**3/  where  n  is  sum 
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of  the  terminals  and  nonterminals  in  the  grammar).  Thus*  it  seems 
that  degree  (2/1)  is  too  big  and  degree  (1*1)  is  too  small.  Since 
most  grammars  for  programming  lanouages  are  nearly  symbol  pair 
grammars*  the  MSP  algorithm  C10D  uses  a  degree  (1*1)  function  with 
tour  values  (stack*  don't  stack*  undefined*  invalid  pair)  and 
reverts  to  a  (2*1)  predicate  only  for  pairs  in  which  the  (1*1) 
predicate  is  undefined. 

2.1.2.   MSP  AND  PRODUCTION  SELECTION 


A  mixed-strategy  approach  [10]  is  also  used  for  choosing  the 
correct  production.  After  sorting*  the  MSP  algorithm  categorizes 
the  productions  as  follows: 

1.  Always  correct*  if  this  is  the  first  match; 

2.  Resolvable  by  checking  n  symbols  in  the  text; 

3.  Resolvable  by  checking  m  symbols  in  the  stack 
below  the  right  part; 

A.  Solvable  by  using  (m*n)  contex  in  the  stack  and  the  text; 

and 
5  .  Error . 
After  finding  a  match*  the  production  is  checked  against  its 
category  according  to  the  above  order.  It  is  accepted  immediately 
if  it  is  in  category  1/  and  the  indicated  tests  are  performed  on  the 
others.  If  a  production  is  rejected*  the  search  for  a  match  is 
cont i nued . 
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2.?.   THE  MSP  PASCAL  GRAMMAR 


A  s*»t  of  productions  was  developed  for  the  PASCAL  language. 
The  MSP  PASCAL  grammar  [Appendix  AD  was  used  by  the  grammar  analyzer 
to  generate  the  tables  required  by  the  MSP  algorithm  as  outlined 
above.  A  feu  manipulations  of  the  production  rules  [Appendix  A3 
were  required  to  make  the  MSP  PASCAL  grammar  acceptable  to  the 
MSF(2/1;1/1)  grammar  analyzer. 
For  exampl e : 


rule  159 
160 

and 

rule  177 
178 


<s  i  an  2>  :  :  =  ♦ 
<sion  2>  ::=■  - 


<si  gn>  : :  =  ♦ 
<  s  i  «->  n  >  :  :  =  - 


If   the   four   rules   above   were  merged  into  two/  the  error  message 
'stacking   cannot   be   made   with   (2/1)  context'  and/or  'production 
cannot   be   distinguished   with   (1/1)   context'   would  be  generated 
during   the   grammar   analysis   phase.   Some  of  the  production  rules 
were  also  created  because  of  semantic  considerations. 
For  ex  emple  : 
rule  46         <repeat  head>  ::=  REPEAT 
was   inserted   there   so  that  detection  of  the  beginning  of  a  REPEAT 
statement   could   be   communicated   to   the  semantic  routines  by  the 
syntax  parser. 
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After  the  compiler  has  been  written*  it  would  be  rather 
difficult  to  adapt  to  changes  on  the  MSP  PASCAL  grammar.  Thus*  it 
is  advisable  to  resolve  the  grammar  specifications  carefully  before 
advancing  to  the  phase  of  semantic  analysis  and  code  generation. 
Even  after  the  grammar  is  accepted  by  the  grammar  analyzer*  there 
remains  a  risk  that  the  grammar  might  not  represent  the  intended 
taroet  lanquaqe*  or  that  semantic  considerations  miaht  require  the 
creation  of  additional  productions. 

2.3.   DIFFERENCES  IN  SYNTAX  BETWEEN  THE  MSP  PASCAL  GRAMMAR  AND 
THE  STANDARD  PASCAL  GRAMMAR 

The  standard  PASCAL  syntax  was  presented  as  a  top-down  grammar 
[53.  Several  difficulties  occurred  during  the  process  of  generating 
the  MSP  PASCAL  grammar  for  this  implementation*  partly  because  of 
restraints  imposed  by  MSP  algorithm*  and  partly  because  of  the  fact 
that  the  top-down  grammar  was  restructured  for  a  bottom-up  parsing 
analyzer.  In  addition  to  the  extensions  presented  in  chapter  7* 
there  are  two  minor  differences  between  the  syntax  specification  of 
this  grammar  and  that  of  the  PASCAL  Report.  These  are  explained  in 
the  sub-sections  below. 

2.3.1.   THF  EMPTY  STATEMENT 


Since  the  semicolon  [  ;  D  is  considered  as  a  statement  separator 
instead  of  a  terminator*  the  empty  statement  presents  some  problems 
in  making  the  MSP  PASCAL  grammar  acceptable  to  the  MSP  grammar 
analyzer.   The  empty  statement  must  be  explicitly  represented  in  the 
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MSP  PASCAL  grammar  wherever  it  is  allowed.   A  considerable  amount  of 

manipulation  of  the  grammar  is  required  in  order  to  make  the  grammar 

acceptable.   A   compromise  is  suggested   in  this  implementation  to 

allow  only  restricted  usaae  of  the  empty  statement. 

Empty  statements  are  most  commonly  used  at  the  following  two 
loc  at  ions  : 

a)  Before  keyword  END  or  UNTIL;  and 

b)  After  <label>  : 

The  first  usage  is  possibly  due  to  the  programming  habit 
inherited  from  other  languages  (e.g./  PL/I/  ALGOL).  The  PASCAL 
lannuaqe  does  allow  it/  but  interprets  it  as  an  empty  statement 
between  •;■  and  •  E ND • / ' UNT I L • . 


The  second  usage  arises  under  certain  situations/  because  there 
is  no  RETURN  statement  in  PASCAL.  Return  is  implicitly  executed  at 
the  physical  end  of  a  procedure.  This  should  not  be  considered  as  a 
weak  point  of  PASCAL;  it  reflects  the  philosophy  that  disciplined 
pronramming  needs  no  RETURN  statement.  However/  should  multiple 
return  points  be  required/  an  equivalent  return  statement  must  be 
supplied  by  a  GOTO  statement/  together  with  a  label  before  the  last 
END  of  the  procedure.  For  example: 
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PROCEDURE  multi  return; 


GOTO  100; 


return 


100:   end; 


'empty  statement  between  :  &  END 


The  empty  statements  are  not  included  in  the  MSP  PASCAL  grammar 
dirrectly.  The  ability  to  recognize  these  restricted  empty 
statements  was  accomplished  by  the  scanner.  This  is  another  area 
where  the  scanner/  with  the  knowledge  of  local  context/  can  simplify 
the  job  of  the  syntax  analyzer. 

2.3.2.   FILE  VARIABLE  AND  POINTER  VARIABLE 


From  the  original  PASCAL  syntax  in  the  Revised  Report  [53: 
<file  buffer>  ::=  <file  variable>  oi  .  .(a) 

<file  variable>  ::=  <variable>  .  .(b) 

and 

<referenced  variable>  ::=  <pointer  variable>  a    .  .(c) 
<pointer  variable>  ::-  <variable>  .  .(d) 

There  is  not  enough  context  to  distinguish  between  productions 
(b)  and  (d) .  Three  possible  solutions  to  the  above  problem  are 
considered  here.  The  first  one  is  to  treat  the  <file  variable>  as  a 
terminal  and  to  delete  rule  (b).  The  second  approach  is  simply  to 
replace   the  %    in  rule  (a)  by  a  new  symbol  $ .   The  third  approach  is 


Page   14 


to  treat  the  <file  variable>  as  a  physical  reference  to  the  buffer. 
With  the  last  approach*  the  <file  variable>  and  the  <pointer 
variable  >  are  syntactically  and  semantically  the  same/  and  the 
above  four  productions  can  be  merged  into  two  rules.  The  second 
approach  was  used  temporarily  for  the  current  version  of  the  PASCAL 
compiler;  however*  the  decision  may  be  changed  in  the  next  version. 
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3.   THE  SCANNER  AND  THE  SYNTAX  ANALYZER 

The  first  process  of  the  compiler  is  lexical  analysis  or 
scanning.  The  input  to  the  scanner  is  a  stream  of  characters  which 
constitutes  the  source  prooram;  the  output  of  the  scanner  is  a 
stream  of  tokens  which  serves  as  the  input  to  the  syntax  analyzer. 
Tokens  include  identifiers*  reserved  key  words*  constants*  and 
single  and  double  character  delimiters.  The  scanner  also  discards 
some  textual  elements*  such  as*  spaces  and  comments.  A  scanner  may 
be  programmed  as  a  separate  pass.  Under  this  one-pass  compiling 
system*  the  scanner  acts  as  a  subroutine  called  by  the  syntax 
analyzer  whenever  the  syntax  analyzer  needs  a  new  token. 

3.1.   THE  SCANNER  OF  THIS  COMPILING  SYSTEM 


The  scanner  for  this  compiling  system  was  hard-coded.  The 
structure  of  a  scanner  is  quite  simple  and  may  be  treated  as  a 
finite  state  machine.  In  fact*  this  scanner  performs  more  functions 
other  than  those  given  above.  For  example*  it  controls  the  listings 
of  the  source  program.  The  listings  include  headings  for  each  page* 
statement  numbers*  nesting  level*  and  block  number  for  identifying 
the  body  of  each  procedure  or  function.  It  also  includes  conversion 
routines  which  convert  digit  streams  to  internal  representation. 
Moreover*  this  scanner  has  an  important  role  in  compiling  READ  and 
WRITE  procedures*  which  will  be  further  discussed  in  the  next  two 
sections. 
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3.1.1.   THE  PROCEDURES  READ  AND  WRITE 


The  PASCAL  Report  C 2 1  D  defines  the  standard  procedures  READ  and 
WRITE  to  facilitate  access  to  the  standard  tiles  INPUT  and  OUTPUT/ 
respectively.  This  implementation  extends  the  READ  and  WRITt 
procedures  to  any  text  file.  The  combination  of  READ*  WRITE  and  EOL 
provi  Jes  equivalent  services  to  the  combination  of  READ/  WRITE/ 
READLN  and  WRITELN  in  the  Revised  PASCAL  Report  [53.  Notice  that 
the  syntax  in  the  Revised  Report  specifies  that  the  file  name/  if 
thfre  is  one/  be  the  first  parameter.  It  is  suggested  that  the 
separation  of  file  specification  from  parameter  lists  would  enhance 
the  readability  of  a  program.  For  this  reason/  it  was  decided  to 
use  the  syntax  specification  of  the  PASCAL  compiler  from  the  MESH 
research  project  [193.  As  implemented  by  the  MTSH  project/  the  file 
specification  is  moved  to  the  outsioe  of  the  parameter  lists.  For 
example/  the  statement: 

READ  FILE_X  (intl  /  int?) 
would   read   two  inteoers  from  file  FILE_X.   In  this  implementation/ 
files  could  be  declared  as  direct  access  files/  also  READ/WRITE  have 
been   further   extended  to  access  those  files  randomly.   These/  with 
other  extensions/  will  be  discussed  in  more  detail  in  Chapter  7. 

3.1.2.   THE  SCANNER  AND  READ/  WRITE  PROCEDURES 


The  syntax  specifications  for  callino  READ  and  WRITE  procedures 
are  non-standard/  and  can  be  treated  as  a  totally  different  qrammar. 
They  are  different  from  standard  syntax  in  that  their  parameter 
lists   allow   for   a   variable   number  of  parameters.   Moreover/  the 
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actual  parameters  can  be  certain  types  other  than  CHAR;  in  which 
case/  the  data  transfer  is  accompanied  by  an  implicit  data 
conve  rsion . 

It  is  possible  to  include  special  production  rules  in  the  MSP 
PASCAL  grammar  to  handle  READ  and  WRITE  proceaures/  rut  this  would 
unduly  increase  the  size  of  the  grammar.  Even  with  this  approach* 
the  scanner  has  to  recognize  READ  and  WRITE  as  special  keywords. 
Since  the  scanner  has  to  know  local  syntax*  it  was  decided  to  let 
the  scanner  handle  READ  and  WRITE  statements*  rather  than  to  change 
MSP  PASCAL  qrammar  drastically. 

READ  and  WRITE  statements  were  first  expanded  by  the  scanner  so 
thc;t  they  may  be  treated  by  the  syntax  analyzer  as  an  ordinary 
procedure.  For  example  (supposinq  i  and  j  have  been  declared  as 
integers)  : 

WRITE(i*j:2)       would  be  expanded  as 

HEGIN  WRITE(i*10),*  WRITF(j*2)   END 
where   10   appears   in  the  first  WRITE  statement  because  the  default 
width   is   10  for  integer.   This  approach  is  /in  some  sense*  similar 
to  macro  expansion  with  default  parameters. 

3.2.   SYNTAX  ANALYSIS 


The   basic   compiling   loop  C10D  for  the  syntax  analysis  can  De 
described  with  the  followinq  PASCAL  statements: 
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WHI LF  compi I ing  DO 
BEGIN 

WHILF  stackinn  DO 
BEGIN 


scan; 

end; 

reduce; 

end; 


stack  token"; 
qet  next  token" 


where: 

compilino  is  a  looical  variable  which  is  turned  on  initially* 

and  turned  off  when  eno-ot-file  has  encountered; 
stacking  is  the  logical  decision  function  which/  based  on  thp 

MSP  st ack i nq-de c i s i on  predicate/ 

a)  returns  a  TRUE  value  if  a  token  is  to  be  stacked/ 

b)  returns  a  EALSE  value  if  a  reducion  in  syntax 
tree  is  so  desired; 

scan  is  a  procedure  which  returns  the  next  token;  and 
reduce  is  a  procedure  which/  based  on  MSP  production  selection 
rules/  looks  up  a  production  rule  and  makes  the 
syntax  reduction  after  callinq  the  semantic  analyzer 
to  produce  the  associated  code. 


Since  the  compiler  was  encoded  in  FORTRAN/  the  syntax  analyzer 
car  he  transported  to  any  other  computer  which  supports  the  FORTRAN 
I  a  n  c;  u  a  q  e  . 
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A.   SYMBOL  TABLE  MANAGEMENT 

The  principal  function  of  the  symbol  table  is  to  associate  an 
identifier  with  its  declaration.  The  structure  of  the  symbol  table 
usually  reflects  the  desion  of  a  compiler.  In  this  i mp lement at i on / 
the  symbol  table  contains  keywords  as  well  as  predefined  functions/ 
procedures  and  type  identifiers- 
Chained  hash  addressing  techniques  [3/7/113  were  utilized  for 
symbol  table  construction.  Each  entry  in  the  symbol  table  has  a 
c  h  .*  i  n  field  which  may  contain  zero  or  a  pointer  to  another  entry 
whose  identifier  has  the  same  hashed  value.  In  addition  to  the 
symbol  table/  this  compiler  maintains  a  hash  table  whose  elements/ 
called  buckets/  are  empty  initially.  Fach  bucket  either  contains 
2ero  or  points  to  the  head  of  a  linked  list  which  includes  all  the 
identifiers  with  the  same  hashed  value. 

If  the  identifier  S  to  be  hashed  is  more  than  two  characters 
(one  word)/  a  single  word  S*  is  derived  by  adding  all  words  of  S. 
The  hashed  address  is  then  calculated  as: 

address  of  bucket  =  C  S*  MOD  ( s i ze_of _hash t ab  le )  D  ♦  1  . 
The  hash  function/  though  simple/  does  have  satisfactory  results. 

4.1.   STRUCTURE  OF  AN  ENTRY  IN  THE  SYMBOL  TABLE 


The   data   structure   of   an   entry   in  the  symbol  table  can  be 
formulated  in  these  PASCAL  statements: 
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TYPF"  i  n  d  e  x  /  I  i  n  k  =  integer; 

al  fa  -  RECORD 

ptr:     index;     "index  into  string-pool" 
s_long:  integer    "ft    of  chars  for  the  identifier 

end; 

addr_pnir  =  RECORD 

I  eve  I  :   integer; 
offset:  i  nteger 

end; 


s_type  =  RECORD 

type:  (undefined/  scalar, 
file/       array/ 
record/     po inter/ 
procedure_id/ 
keyword/ 
subrange_t ype / 
reference/  field_id/ 
file_name/  packed:    tool; 

end; 


set  / 

list/ 

f unct  i  on_i  d/ 

t ype_id 

const  ant  _i  d 

label); 


s_ent  r y  = 


RECORD 

id_name : 
i  d_addr : 
i  d_type : 
i  d_  lenqt  h 
brot he  r : 
son : 

end; 


alfa; 

addr_pa  i  r ; 
s_t ype; 
integer; 
link; 
link 


VAR  symbol_table:  ARRAY  C1..tablesize!)  of  s.entry; 

string-pool:  PACKED  ARRAY  C1  .  .poo  Is i ze]  of  char; 
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In  order  to  maintain  a  fixed  length  entry  for  the  symbol  taole/ 
an  identifier  is  represented  by  storing  its  length  together  with  an 
index  into  the  string  pool.  The  "id. length "#  a  field  identifier  of 
the  "s_entry"/  indicates  the  size  of  the  storage  allocated  to  each 
structure/  and  the  "type"  of  "s_type"  specifies  the  type  of  an 
identifier. 

There    are   also   four   flags   used   to   associate   additional 

attributes  with  an  identifier: 

reference  -  is  set  to  true  for  the  formal  parameter  called  by 
reference; 

field_id   -  is  set  to  true  for  an  identifier  which  is  also 
part  of  a  record; 

file_name  -  is  set  to  true  for  an  identifier  which  is  also 
a  file  name; 

packed     -  is  set  to  true  for  packed  structures. 

A. 2.   REPRESENTING  STRUCTURE  IN  THE  SYMBOL  TAbLE 

The  data  structure  can  be  represented  by  having  addditional 
fields  as  links  172.  PASCAL  has  no  complex  COBOL-like 
Qualification  rules;  referencina  an  item  inside  a  record/  except 
explicitly  specified  with  a  "WITH"  statement/  has  to  start  from  the 
roct.  As  a  consequence/  only  two  links/  the  brother  and  son/  are 
sufficient  to  represent  various  structures. 


Three  examples/  shown  in  Figs.  2/  3/  and  A/  are  used  to 
demonstrate  how  structures  were  constructed  in  this  implementation. 
Each   node   in   these   examples  has  three  fields  -  INFO/  BROTHER  and 
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S 0 r-  .   The   INFO   represents  the  combined  information  of  the  id_name* 
id_addr*  id_type  and  id_lenqth.   A  node  is  shown  as  in  Fiq.  1. 


INFO 


|  BROTHER  |     SON     | 


Fia.1.   A  node  showing  portions  of  the  information 
stored  in  an  entry  of  the  symbol  table. 


VAR  d:  ARRAY  CO. .2]  OF  ARRAY  C1..53  OF  INTEGER; 


!• 3 


array 


°~?      NM 


: array 


1-*     KN 


:  i  ntege  r       \\ 


Fia.2.    The  structure  representation  for  a 
two  dimensional  array. 
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TYPE  a  =  ARRAY  CI ..53  OF  INTEGER; 
b  =  ARRAY  CO.  .?]  Ot    a; 

VAR       c     :     b; 


c : 


S 


b  :  type  \ 


1 


:  array 


Th 

;  °--?      1\N 


rtype  |\ 


array 


hH     NNI 


:integer  |\|\| 


Fiq.3.    The  structure  representation  for  a  two  dimensional 
array  with  user-defined  data  types  'a'  and  'b*. 
This  array  is  equivalent  to  that  of  Fiy.2. 
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VAR  a:  RECORD  OF 

b  :  I  N  T  6  F  R  ; 

c:  ARRAY  C 1  .  .53  OF  INTEGbR; 

d:  INTEGER 

end; 


airecord  \ 

i 

1 

b: scalar 

\ 

c  : 

f 

^r 

: a  r ray 

\ 

' 

:  1  ..5 

ss 

' 

d : sea  I  ar   \ 

. 

I  \ 

'     \ 

[ 

:integer  |\\l 

Fig. A.    The  structure  representation  for  a  record 
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5.   RUNTIME  STORAGE  MANAGEMENT 

There  are  two  types  of  data  areas  in  PASCAL:  one  is  the  runtime 
stack  similar  to  that  used  in  AL60L-60  C12/14J;  the  other  is  for 
dynamic  storage  allocation  of  pointer  type  variables.  One  important 
lannuaoe  feature  of  PASCAL  is  that  all  space  attributes  are  known  at 
compile  time.  This  feature  simplifies  storaqe  allocation  because 
templates/  which  describe  attributes  at  runtime/  are  not  required. 
For  the  same  reason*  the  compiler  can  generate  directly  all  the 
necessary  code  for  variable  reference;  thus/  the  more  efficient  code 
may  be  obt  ai  ned . 

5.1.   STACK-BASED  STORAGE  MANAGEMENT 

The  characteristic  of  the  nested  last-in/  first-out  structure 
of  procedure  or  function  calls  in  PASCAL  makes  stack-based  storage 
manaqement  a  natural  choice.  At  the  start  of  the  execution  of  a 
PASCAL  program/  a  contiguous  space  is  assigned  as  a  stack  which  is 
initially  empty.  When  a  subprogram  is  called/  a  new  activation 
record  is  created  on  top  of  the  stack.  Termination  of  a  subprogram 
then  causes  its  deletion  from  the  stack.  One  major  advantage  of 
this  orqanization  is  that  it  solves  automatically  the  problems  of 
st crane  recovery/  compaction  and  reuse. 


The  size  of  the  runtime  stack  used  in  this  compiler  is 
defaulted  to  the  sum  of  the  storage  required  by  all  variables 
declared  in  the  program  and  the  I/O  working  area  associated  with 
each   file  declaration.   This  amount  of  space  permits  the  nesting  of 
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calls  to  all  subprograms  once  without  overflowing  the  runtime  stack. 
However/  overflow  of  the  stack  could  happen  for  highly  recursive 
subprogram  calls.  It  is  a  waste  of  memory  space  to  allocate  a  very 
hi.-  runtime  stack  without  any  prediction  from  the  programmer.  Since 
the  programmer  is  the  only  one  who  knows  the  degree  of  recursion  of 
his  program/  one  possible  solution  is  to  include  a  directive  to  the 
compiler  which  specifies  the  size  of  the  stack.  Another  better 
solution  is  to  let  the  operating  system  allocate  space  for  the 
runtime  stack.  Because  of  the  vi rtua I -pageo  memory  system  supported 
by  the  MAX  IV  operating  system/  it  is  possible  to  invoke  an 
executive  service  routine  to  allocate  more  space  for  the  runtime 
stack  when  a  page  fault  occurs.  This  approach  is  more  appealing  and 
miuht  be  implemented  in  the  next  version. 

5.2.   HEAP  STORAGE  ALLOCATION 


The  term  'heap'  refers  to  a  block  of  storage  within  which 
pieces  are  allocatea  ana  freed  in  a  relatively  random  manner  [133. 
In  PASCAL/  pointer  variables  refer  to  variables  allocated  on  a  heap/ 
and  they  are  generated  by  calling  the  standard  procedure  NEW.  If  a 
pointer  type  P  consists  of  an  unbounded  set  of  values  pointing  to 
elements  of  a  given  type  T/  then  P  is  said  to  be  bound  to  T  C5D. 
Therefore/  the  procedure  NEW  requires  an  implicit  parameter  which 
specifies  the  size  of  storage  required  by  the  type  T  associated  with 
the  pointer  P.  It  was  also  decided  to  implement  DISPOSE/  the 
opposite  of  the  procedure  NEW/  as  a  predefined  procedure.  The 
procedure  DISPOSE  relieves  the  user  of  the  responsibility  for 
maintaining   his   own   free   element  list/  and  it  also  achieves  more 
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efficiency   in   storage   utilization.   The   documentation  of  NEW  and 
DISPOSE  is  listed  in  Appendix  D. 


5.3.   STATIC  STORAGE  MANAGEMENT 


AN  EXTENSION 


Motivated  by  the  necessity  for  initializing  big  tables/  common 
variables  were  introduced  as  a  local  extension  CChapter  7  ]  .  The 
allocation  and  initialization  of  common  variables  are  handled  by 
either  the  link-loader  or  the  link-editor  of  the  MAX  IV  system 
utilities. 

5. A.   DATA  STRUCTURES 

This  section  will  discuss  the  various  PASCAL  data  structures; 
some  of  the  features  have  been  extended  in  this  compiler*  while  some 
of  them  are  to  be  incorporated  in  the  future. 

5.4.1.   STORAGE  FOR  ELEMENTARY  DATA  TYPES 


The  regular  word  size  of  this  machine  is  16  bits*  and  a  byte 
has  8  bits.  There  are  four  standard  types  for  variables  and  all  of 
them  are    treated  as  predefined  identifiers  of  subrange  type: 

a.  integer   -2**15  to  2**15-1; 

b.  char      1  to  127; 


c  .  boo  I 


o .  rea I 


true  or  false;  the  internal  representation  is  1  for 
true  and  0  for  false; 

not  implemented  in  this  version. 
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b.  A.  2.       ARRAY 


Multidimensional  arrays  are  mapped  into  memory  in  row  major 
order.  In  the  present  version/  they  must  be  declared  as  an  array  of 
arrays;  for  example/  a  two-dimensional  integer  array  is  declared  as 

VAR  matrix:  ARRAY  Ca..b3  OF  ARRAY  Lc.dl    OF  integer; 
or  it  can  be  defined  as 

TYPE  vector  =  ARRAY  Cc.dT  OF  integer; 

VAR  matrix:  ARRAYCa..b]  OF  vector; 
The  (i/j)th  elememt  of  matrix  is  then  referenced  as  ma t r i x C i 3 C j D . 
However/   this   restriction   will   be  removed  in  the  near  future/  so 
th^t    the    convenient    abbreviations    can    also    be   used   for 
mu  I  t  i  cii  mens  i  ona  I  arrays: 

VAR  matrixCa..b/c..dD  of  integer; 
and  the  (i#j)th  element  can  be  referenced  as  matrixCi/j3. 

5  .A  .3.   RECORD 

The  variant  part  of  a  record  is  not  implemented  on  this  version 
of  the  compiler.  One  simplified  way  to  implement  variant  records  is 
to  reserve  the  maximum  storage  requested  among  all  variants.  With 
this  approach/  the  property/  that  the  S( ace  attributes  of  all 
variables  are  known  at  compile  time/  is  preserved. 

5. A. A.   FILE 


The  compilation  of  a  file  declaration  includes  the  allocation 
on  the  runtime  stack  an  I/O  buffer/  and  a  block  of  storage  which 
contains   the   user-file-table   C173   and   control  variables  for  the 
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buffer.  The  size  of  the  1/0  buffer  is  set  to  256  bytes  because  that 
is  the  most  commonly  used  size  of  a  sector  on  a  disk  or  a  magnetic 
tape  on  the  M0DC0MP  system.  At  present*  the  standard  files  INPUT 
and  OUTPUT  are  implemented  as  implicitly  declared  in  the  main 
proqram.  However/  they  can  also  be  implemented  as  formal  parameters 
of  main  programs  such  that  buffers  will  only  be  allocated  when 
necessary.  The  structure  of  a  file  has  been  extended  and  is  further 
discussed  in  Chapter  7. 

5. A. 5.   SFT  TYPES 

A  set  type  defines  the  set  of  values  that  is  the  powerset  of 
its  base  type*  and  the  base  type  must  be  a  scalar  type.  Set  type  is 
not  implemented  in  this  version.  However*  it  is  possible  to 
implement  a  set  as  a  bit  string.  Since  the  word  size  is  16  bits*  it 
is  natural  to  reserve  a  multiple  of  16  bits  for  each  set.  Thus*  it 
is  suqgested  that  at  least  8  words(12fc  bits)  te  allocated  for  each 
set  if  sets  are  implemented.  In  doing  so*  a  set  may  include  the 
whole  character  set  and  thus  becomes  very  useful. 

5.4.6.   PACKED  STRUCTURE  TYPE 


In  PASCAL*  a  type  definition  prefixed  with  the  symbol  PACKED 
requires  the  compiler  to  economize  storage  requirements*  even  at  the 
expense  of  additional  execution  time  and  a  possible  expansion  of 
code.  The  implementation  of  general  packed  structures  is  rather 
complex*  and  will  increase  the  size  of  the  basic  compiler.  Since 
many   of   the   application   programs   on   the   local   system  include 
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character   string  manipulation/  it  was  decided  that  the  packed  array 
of  characters  be  implemented  on  this  version. 

The  packed  array  of  characters  was  implemented  without  too  much 
overhead.  This  is  because  the  instruction  set  of  the  host  machine 
allows  direct  addressing  and  manipulation  of  bytes.  Since  two 
characters  can  be  packed  into  a  16  bit  word/  a  50%  saving  in  storage 
can  be  achieved  with  only  small  loss  in  efficiency.  Strings  with 
n>1  characters  were  implemented  as 

PACKED  ARRAY  C1..n]  OF  char; 
Therefore/  a  string  constant  can  also  be  used  in  the  context  where  a 
packed   array  is  allowed.   For  example/  if  a  string  is  declared  as  a 
const  ant  i  n 

CONST   b  =  'a  strino'; 
then  the  first  character  of  the  strinq  can  be  referred  to  as  bC1D. 


5. A. 7.   ACTUAL  -  FORMAL  PARAMETERS 


As  stated  before/  there  are  two  ways  to  pass  parameters: 
either  by  reference/  or  by  value.  If  a  formal  parameter  is  called 
by  reference/  only  one  word  is  reserved.  The  reserved  word  holds 
the  runtime  address  of  the  actual  parameter  passed  by  the  calling 
sequence.  If  a  formal  parameter  is  called  by  value/  a  block  of 
storage  is  allocated  as  specified  by  its  declaration.  Some 
optimization  was  performed  to  minimize  code  for  passing  parameters. 
If  the  actual  parameter  is  of  a  simple  data  type/  the  value  of  the 
actual  parameter  will  be  passed  directly  to  the  subprogram. 
Otherwise/   if   the   actual   parameter  is  of  a  structured  data  type/ 
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only  the  address  of  the  structure  will  be  passed/  and  the  receiving 
sequence  of  subprogram  will  copy  the  structure  into  the  local  data 
area. 
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6.   SEMANTIC  TRANSLATION 

The  semantic  analysis  was  accomplished  under  the  control  of  the 
subroutine  SYNTHESIZF.  When  a  reduction  U::=X  is  recognized 
according  to  the  MSP  PASCAL  grammar/  the  syntax  analyzer  calls 
SYNTHFSIZF*  with  the  production  number  as  the  argument.  In  other 
words/  before  the  handle  X  of  the  sentential  form  is  reduced  to  the 
nonterminal  u*  some  semantic  actions  may  take  place.  Depending  on 
the  production  number*  semantic  actions  may  involve  entering  or 
checkino  information  in  the  symbol  table*  generating  assembly  code 
and  associating  semantic  information  with  the  newly  created 
nonterminal  U  . 

6.1.   THE  SEMANTIC  ANALYZER  AND  CODE  GENERATION 


because  this  is  a  one-pass  compiler*  the  semantic  analyzer  and 
code  generation  routines  are  closely  related  to  each  other.  The 
communication  between  code  generation  routines  and  the  semantic 
analyzer  is  by  the  use  of  the  semantic  stack  and  the  loop  stack. 
The  semantic  stack  holds  the  semantic  attributes  associated  with  a 
particular  nonterminal.  Fach  entry  in  the  semantic  stack  consists 
of  two  words*  where  the  first  word  specifies  the  status  of  a 
nonterminal*  and  the  second  word  is  used  as  a  modifier  of  that 
status.  The  structure  for  an  entry  on  the  semantic  stack  is  listed 
in  Appendix  C.  The  loop  stack  is  used  to  store  the  address 
associated  with  the  WHILE*  REPEAT*  FOR*  and  IF  statements.  The 
function  for  the  loop  stack  is  to  maintain  the  scope  of  those 
statements  and  to  provide  labels  for  branch  instructions  during  code 
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qeneration.  Although  the  semantic  stack  and  loop  stack  can  be 
combined  into  a  single  stack/  they  were  maintained  separately  for 
easier  debugginq. 


The  sequence  to  compile  an  expression  C+0  will  be  given  as  an 
example  to  summarize  the  compiling  process:  C  is  first  recognized 
as  an  identifier  token  by  the  scanner;  the  syntax  reduction* 
corresponding  to  production  rule  134  [Appendix  A*  <variable 
identifier>  ::=  <identifier>  3*  is  recognized  by  the  syntax  analyzer 
which*  in  turn*  calls  SYNTHESIZE  with  134  as  the  argument.  The 
SYNTHESIZE*  with  the  knowledge  that  production  134  is  used  for 
reduction*  first  calls  another  semantic  routine  LOOKUP  to  check 
whether  C  has  been  correctly  oeclared  before  pushing  the  semantic 
attributes  of  C  into  the  semantic  stack.  Through  the  same  process* 
the  semantic  attributes  of  D  are  then  pushed  into  the  semantic 
stack.  After  other  reductions  which  invoke  no  additional  semantic 
actions  are  applied*  the  reduction  corresponding  to  production  rule 
155  [Appendix  A*  <simple  expression)  ::=  <simple  expression)  ♦ 
<term>  ]  is  recoqnized*  and  the  rule  number  155  is  passed  to  the 
SYNTHESIZE.  A  subroutine  BINOP*  which  is  next  invoked  by  the 
SYNTHESIZE*  checks  the  type  of  C  and  D*  generates  code  to  perform  an 
add  operation*  and  updates  the  semantic  stack. 
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<S.2.   CODE  GENERATION  ROUTINES 

A  set  of  routines  was  designed  for  code  generation  and  simple 
code  optimization.  Some  of  these  code  generation  routines  and  their 
basic  program  logic  will  be  discussed  below. 

6.2.1.   REGISTER  ALLOCATION  ROUTINES 

The  register  assignments  are  listed  in  Appendix  F/  and  several 
routines  are  involved  in  generating  code  to  make  efficient  use  of 
the  accumulators.  The  semantic  status  of  an  operand  is  always 
specified  by  a  pointer  which  points  to  one  entry  on  the  semantic 
stack.  The  subroutine  INACC  is  used  to  check  whether  the  operand  is 
already  in  an  accumulator.  Another  subroutine/  PIKACC/  is  used  to 
search  for  either  a  single  register  or  a  register  pair/  depending  on 
th^  operation  to  be  performed.  If  none  of  the  accumulators  is  free/ 
arbitrary  accumulators  are  pickea  by  the  PIKACC  for  replacement. 
The  routine  FACC  is  used  to  force  the  operand  or  the  runtime 
absolute  address  of  the  operand  into  an  accumulator.  If  the  operand 
is  not  in  an  accumulator/  FACC  then  loads  the  operand  into  free 
accumulators  after  calling  PIKACC. 

6.?. 2.   THE  BINOP  ROUTINE 


With  the  operator  passed  as  the  araument/  the  code  generation 
for  a  binary  operator  was  managed  by  a  generalized  routine  BINOP. 
The   routine   BINOP   always   examines   the   top   two   entries  on  the 
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semantic  stack  to  obtain  the  semantic  information  of  the  two 
operands.  The  routine  usually  forces  the  left  operand  into  an 
accumulator.  However/  in  order  to  optimize  the  code/  the  routine 
first  checks  whether  any  operand  is  already  in  an  accumulator  for 
commutative  operators.  The  same  check  is  also  applied  to  a 
relational  operator/  and  the  opposite  operation  is  performed  if  the 
left  operand  is  in  the  memory  while  the  right  operand  is  already  in 
an  accumulator.  In  case  both  operands  are  constant/  the  indicated 
operation  will  be  executed  at  compile  time.  Since  the  code  for 
array  reference  was  accomplished  partly  by  the  BINOP  routine/  the 
reUtive  address  of  the  element  is  calculated  at  compile  time  if  the 
index  is  a  constant. 

6.3.   AN  EXAMPLE  FOR  CODE  GENERATION 

Many  code  generation  actions  are  straightforward/  most  of  them 
consist  of  a  few  statements  embedded  in  the  SYNTHESIS  routine.  The 
code  can  often  be  generated  by  explicitly  creating  entries  on  the 
semantic  stack/  and  followed  by  calling  code  generation  routines. 
The  sequences  to  generate  the  code  for  iteration  control  of  a  FOR 
statement  will  now  be  described  as  an  example.  The  code  to  be 
generated  includes  implicit  incrementing  (or  decrementino)  and 
testino  of  the  control  variable.  The  steps  for  code  generation  are 
as  follows: 


Push  address  of  control  variable  into  semantic  stack; 
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Duplicate  the  address  of  control  variable; 
lush  constant  1  into  semantic  stack; 
Call  BINOP(add)    (or  call  PINOP(sub)); 
rail  assign; 

lush  the  address  of  the  temporary  location/  which  holds  the 
final  value  of  the  control  variable/  into  semantic  stack; 

Call  filNOP  (equal  )  ; 

enerate  conditional  branch  instruction. 

The  first  call  to  the  subroutine  B I H 0 P  Generates  the  code  to  perform 
the  add  or  sub  operation  (control  variable  +/-  1)/  and  the  routine 
ASSIGN  generates  code  to  assign  the  computed  result  back  into  the 
control  variable.  The  second  call  to  the  subroutine  B1N0P  generates 
code  to  compare  the  control  variable  and  the  final  value;  the 
logical  value  calculates  in  turn/  affects  the  execution  of  the 
branch  instruction. 

6.  A.    REMARKS  ON  GOTO  STATEMENT 


In  this  implementation/  the  destination  of  a  GOTO  statement 
must  be  inside  the  same  subprogram.  This  is  not  a  severe 
restriction  because  the  GOTO  statement  shoula  be  used  only  under 
unusual  and  uncommon  situations  according  to  structured  programming 
[8],  The  restriction  can  be  removed  by  associating  each  label  with 
a  compile  time  subroutine  level.  If  a  procedure  exit  is  reguired 
for  a  GOTO  statement/  the  exit  sequence  [Appendix  G  ]  could  then  be 
generated/  instead  of  producing  a  simple  branch  instruction. 
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6.5.   ERROR  RbCOVERY 

An  attempt  should  be  made  to  find  as  many  errors  as  possible  in 
a  source  program  during  a  single  compilation.  However/  unlike  the 
compiler  for  PL/C/  this  compiler  does  not  try  to  "correct"  all 
errors.  The  error  recovery  routine  is  responsible  for  generatinn 
error  messaqe/  and  determining  how  to  continue  analyzing  a  source 
program  when  an  error  is  found.  Ely  the  time  an  error  is  detected* 
some  erroneous  code  might  have  already  been  generated.  Therefore* 
the  GO/NO  GO  bit  C 1  "73  will  be  reset  if  any  errors  are  detected*  which 
will  then  cause  the  job-control  processor  to  abort  the  assembler 
that  follows  the  PASCAL  compiler. 

6.5.1.  RECOVERING  FROM  SEMANTIC  ERRORS 

This  is  simply  done  by  generatino  an  error  message  and 
inserting  a  new  symbol  taole  entry  for  undeclared  identifiers. 

6.5.2.  RECOVERING  EROM  SYNTACTIC  ERRORS 


The  approach  used  in  this  compiler  is  similar  to  the  techniques 
used  in  the  XPL  compiler  and  many  other  automatic  bottom-up  parsers. 
When  a  syntactic  error  is  detected*  the  compiler  is  said  to  be  in 
"panic  mode"  and  the  following  two  steps  are  performed: 

1.   The  symbols  in  the  input  stream  are  scanned  and  discarded 
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until  a  token  T  is  found*  which  is  one  of  the  preselected 
tokens.   The  set  of  preselected  tokens  incluaes  '  /'  '  /  '  V  A  R  •  / 
'END'/  'TYPE'/  'BEGIN'/  'FUNCTION'  and  'PROCEDURE'. 
Txamine  and  discard  symbols  popped  from  the  syntactic  stack 
until  a  symbol  x  is  found  such  that  the  token  T  found  in 
step  1  can  leqally  follow  x. 


However/  before  the  compiler  q  o  e  s  to  the  panic  mode/  some  tests 
are  conduted  by  insertinq  a  token  to  see  if  the  error  can  be 
removed.  For  example/  it  is  found  that  many  errors  are  caused  by 
omittino  ';'  at  the  enc  of  a  statement/  therefore/  the  symbol  '  I '  is 
inserted  for  the  test.  Many  ad  hoc  tests  can  ce  done  in  the  same 
manner/  yet  there  is  not  sufficient  data  collected  to  indicate  how 
*p  I  I  they  work. 
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7.   EXTENSIONS  TO  THE  MODCOMP  PASCAL  SYSTEM 

This  chapter  discusses  those  PASCAL  extensions  implemented  on 
this  compiling  system.  All  these  added  features  are  implemented 
brsed  on  the  principle  that  the  extension  must  not  creat  a  situation 
such  that  a  standaro  feature  becomes  unusable. 

7.1  .   COMMON  VARIABLE 


The  PASCAL  lanouaqe  has  no  PL/I-like  INITIAL  statement/  which 
Co  uses  inconvenience  to  many  application  programs.  The  assignment 
and  READ/GET  statements  in  standard  PASCAL  may  be  used  for  variable 
initialization;  however/  both  of  them  are  very  inefficient.  As  an 
example^  it  would  be  clearly  very  difficult  to  initialize  tables  for 
this  table-driven  compiler  if  it  were  to  be  encoded  in  PASCAL.  As  a 
result/  the  common  statement  was  included  as  an  experimental 
extension.  The  main  advantage  in  supporting  this  extension  is  that 
common  variables/  when  used  in  conjunction  with  EXTERNAL  statements 
[Section  8.2]/  supply  a  convenient  way  to  initialize  variables  and 
tables.  That  is/  the  common  variables  can  be  initialized  by 
assembly  pseudo  instructions  of  the  external  procedure  which  is 
written  in  assembly  lanouage.  Another  equally  important  factor  is 
that  this  feature  provides  communication  between  PASCAL  programs  and 
proqrtims  written  in  the  assembly  and  FORTRAN  languages  of  the 
MODCOMP  IV. 
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7.1.1.  SPECIFICATIONS  FOR  ThE  COMMON  VARIABLE 

Common   variables  can  be  declarer)  only  in  the  main  program/  and 

may   contain   only   simple   variables   and   arrays  of  standard  types 

(intecer/char/bool).   The  common  variable  declarations*  if  any*  must 

precede   the   <variable   declaration   part>   and   follow   the   <type 

definition   part>.   The   syntax   changes   in   regard  to  the  standard 

PASCAL  grammar  T53  include 

<block>  ::=  <larel  declaration  part> 

<constant  definition  p  a  r  t  > 

<type  definition  part> 

<common  variable  declaration  part> 

<variable  declaration  p  a  r  t  > 

<procedure  and  function  declaration  part> 

<st f tement  part> 

<common  variable  declaration  part>  :  : =  <empty>  ! 
COMMON  <variable  declaration> 
{  ;  <variable  declaration>  > 

7.1.2.  AN  ALTERNATIVE  APPROACH  FOR  VARIABLE  INITIALIZATION 


There  is  another  possible  solution  for  variable  initialization. 
In   PASCAL/  a  constant  identifier  may  either  be  defined  as  a  number/ 
a   strina/  or  another  constant  identifier.   Constant  identifiers  can 
be   used  for  variable  initialization  if  the  constant  definition  part 
has   been  extended  to  allow  structures  [63.   As  an  informal  example/ 
consider  the  following  sample  source  program: 
CONST  x  =  1; 
y  =  3; 
z  =  ARRAYCx..y]  of  INT  INITC1/2/3); 
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The   rest  of  program  will  treat  zC1D  as  constant  1/  zL21    as  constant 
2  /  etc. 

This  approach  maintains  the  principle  that  a  PASCAL  user  should 
relv  only  on  features  of  the  PASCAL  language.  However/  detailed 
i nvest i uat ion  of  the  modifications  to  the  standard  PASCAL  grammar  to 
facilitate  this  extension  should  be  performed  before  its 
implementation. 


7.?.   EXTERNAL  PROCEDURES 

The  short-term  goal  of  introducing  external  procedures  is  to 
provide  the  PASCAL  program  the  ability  to  call  programs  written  in 
assembly  lanou3oe.  Thes*»  programs/  in  turn/  supply  access  to  all 
system  utilities.  The  long-term  goal  of  having  external  procedures 
as  an  extension  is  to  provide  the  facility  to  have  several  PASCAL 
proar^ms  comoiled  separately  and  linked  before  program  execution. 
This  feature  is  very  helpful  to  large  PASCAL  programs  because  it  is 
not  necessary  to  comcile  all  subprograms  everytime  if  most  of  them 
are  already  proved  to  be  workinq. 

The  feature  of  a  separate  compile  and  link  of  PASCAL 
subprograms  has  not  been  implemented  y  e  t  #  however/  it  will  be 
implemented  in  the  very  near  future.  The  global  variable 
declarations  within  separate  compiled  subprograms  will  also  be 
implemtnetri.  Type  checking  is  possible  when  exactly  the  same 
declarations  for  parameter  lists  anO  global  variables  are  the 
m contained  between  the  main  program  and  the  separate  compiled 
suhproorams.   If   strict   type  checking  for  all  modules  in  a  program 
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is   a   necessity/  a  special  link  editor  has  to  be  wtitten  for  PASCAL 
to  enforce  it. 

7.P.1.   SYNTAX  FOR  EXTERNAL  PROCEDURES  IN  MAIN  PROGRAM 

The  syntax  for  external  procedure  declaration  is  the  same  as 
thjt  for  an  ordinary  procedure/  except  that  the  keyword  EXTERNAL 
must  precede  the  keyword  PROCEDURE/  and  there  may  not  be  any  <body 
blnck>  tor  the  external  procedure.  The  supply  of  a  <formal 
declaration  section>  is  mandatory/  since  the  compilation  of  an 
external  procedure  calls  requires  the  type  specifications  of  all 
parameters. 

1.2.7.        PREPARING  ASSEMBLY  PROGRAM  AS  EXTERNAL  PROCEDURE 

The  receivinq  sequence/  return  sequence/  parameter  passing 
mechanism  and  local  variable  allocation  for  the  assembly  program 
must  be  compatible  with  the  code  generated  by  the  PASCAL  compiler. 
Since  these  conventions  are  both  machine  and  implementation 
dependent/  a  set  of  assembly  macros  were  provided  to  help  users. 
The  definitions  and  specifications  for  those  macros  are  given  in 
Append  i  x  E  - 

7.3.   FORWARD  PROCEDURES 


In  this  one-pass  compiler/  a  procedure  can  be  called  only  after 
its  declaration.  This  restriction  forbids  two  procedures  from  both 
callino  each  other/  and  the  remedy  for  this  shortcoming  is  to  allow 
forward  declaration.   The  syntax  for  a  forwarO  procedure  declaration 
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is  the  same  as  that  for  an  external  procedure/  except  that  the 
keyword  EXTERNAL  is  replaced  by  the  keyword  FORWARD.  To  demonstrate 
the  important  usage  for  forward  procedure  declaration/  the  top-down 
parsing  alqorithm  for  expressions  in  the  PILOT  compiler  (a  test 
proqram/  see  Chapter  is)  is  given.  The  expression  is  parsed  by  using 
the  recursive  descent  method/  based  on  the  following  grammar 

Z  :  :  =  EXP 

EXP  ::=  SEXP  {(>!<!=!>=!<=)  SEXP  > 

SEXP  ::=  C-3  TERM  {(+!=)  TERM  > 

TERM  : :=  FACT  <  (*  !  /)  FACT) 

FACT  ::=  VARIABLE  !  CONSTANT  !  (EXP) 
One   recursive  procedure  is  required  for  each  grammatical  rule.   For 
example/  the  procedure  TERM  for  the  nonterminal  TtRM  is: 


PROCEDURE  TERM; 
BEGIN 

FACT;         "call  FACT" 

WHILE  (CURCHAR=  •*' )  !  (CURCHAR=' /)  DO 
BEGIN 

scan;     "get  next  token" 
fact; 

END 
FMD;      "END  OF  PROC  TERM" 


Because  the  procedures  EXP/  SEXP/  TERM  and  FACT  all  call  each  other 
directly  or  indirectly/  at  least  one  forward  procedure  declaration 
i  s  requi  red  . 


7.4.   FILE  TYPES 


The  MAX  IV  operating  system  [173  provides  four  modes  for  I/O 
transmission  -  Standard  Binary/  Nonstandard  Binary/  Standard  ASCII 
and  Nonstandard  ASCII.   Moreover/  in  order  to  save  secondary  storage 
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sr are  and  transfer  time  on  many  source  records/  there  is  a  special 
convention  for  recording  ASCII  data  for  external  media  storage  on 
the  MODCOMP  system  (data  encoded  according  to  this  convention  are 
called  compressed  ASCII). 


In  the  standard  PASCAL  syntax/  a  file  type  is  defined  as 

<file  type>  ::=  FILE  OF  <type>. 

However/   it   is  desirable  that  the  user  have  the  ability  to  specify 

thr  mode  of  data  format;  therefore/  more  information  about  tiles  may 

be    provided    in   a   PASCAL   program.   The   syntax   tor   the   file 

declaration  was  thus  expanded  to 

<file  type>  ::=  <random>  <packed>  <nonst andard> 

<binary>  FILE  OF  <type> 

<random>  ::=  <empty>  |  RANDOM 

<packed>  ::=  <empty>  |  PACKED 

<nonstandard>  ::=  <empty>  |  NONSTANDARD 

<Mnary>  n-  <empty>  |  BINARY 
The  four  keywords/  RANDOM/  PACKED/  NONSTANDARD  and  BINARY/  represent 
additional  specifications  of  a  file.  The  default  specifications  for 
a  file  are  sequential/  non-packed/  standard  and  ASCII/  respectively. 
Briefly/  RANDOM  indicates  the  ability  to  reference  records  randomly 
on  random  access  devices.  PACKED  indicates  the  files  are  encoded  in 
compressed  ASCII/  while  NONSTANDARD  and  bINARY  refer  to  the  mode  of 
I/O  operation. 
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7.S.   READ/WRITE  PROCEDURES  AND  RANDOM  ACCESS  FILES 


In  standard  PASCAL*  only  the  sequential  file  is  supported;  yet/ 
random  access  to  the  records  of  a  file  is  desirable.  Therefore/  the 
file  declaration  and  READ/WRITF  procedures  were  extended  to 
accommodate  random  access  files.  As  stated  in  section  4.1./  the 
syntax  of  READ  and  WRITE  for  accessing  sequential  files  is 

FEAD/WRITF  file-name  (parameter  lists)  ; 
In   order   to   maintain  consistency/  the  syntax  for  accessing  random 
files  is  modified  to 

READ/WRITE  file-name  Cpos i t i on-i ndex 3  (buffer)  . 
In  the  above  statement/  the  file-name  has  to  be  declared  previously 
as  a  random  file.  The  position -index/  which  indicates  the  position 
of  the  record  on  the  external  device/  has  to  be  an  expression  with 
an  integer  value.  If  the  value  of  the  position-index  is  negative/ 
the  next  record  will  be  read  in  or  written  to  just  as  that  of  a 
sequential  file.  The  buffer/  which  is  passed  to  READ  or  WRITE  as  an 
argument/  is  the  name  of  a  structured  variable  defined  by  a  user's 
program.  This  structured  variable  is  used  as  the  physical  I/O 
buffer/  and  its  size  is  fixed  to  256  bytes  for  the  initial 
experiment.  Fecause  it  is  often  desirable  to  maintain  more  than  one 
buffer  in  core  memory  for  a  ranaom  access  file/  the  buffer  is 
designed  to  be  supplied  explicitly  by  the  user  so  that  as  many 
buffers  can  be  maintained  as  desired. 
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P.   SUMMARY 

A  PASCAL  compiler  was  implemented  based  on  the  scheme  outlined 
in  the  previous  Chapters.  Because  of  the  constraints  imposed  by 
both  the  size  of  the  core  memory  and  the  amount  of  time  available/ 
some  features  of  the  standard  PASCAL*  notably  type  real*  have  yet  to 
be  implemented.  However*  various  extensions  [Chapter  73  were  added 
due  to  demands  of  the  local  environment.  A  predefined  procedure  REX 
[Appendix  D3  was  also  supplied  to  communicate  with  the  executive 
services  provided  by  the  MAX  IV  operating  system.  A  compiler 
supporting  the  core  instructions  of  the  PILOT  language  [183  was 
prepared  by  the  author  as  a  test  program  for  this  PASCAL  compiler. 
Extensions*  such  as  forward  procedure  and  random  I/O*  were  tested  by 
executing  the  PILOT  compiler.  In  addition  to  the  PILOT  compiler*  an 
attempt  has  been  made  to  execute  a  program  designed  to  check  PASCAL 
syntax*  which  was  originally  written  using  the  PASCAL  implementation 
of  the  MESH  [193  project.  During  the  compilation  of  that  program* 
the  empty  statement  problem  [section  3.4.13  appeared  only  once.  The 
PASCAL  syntax  checking  program  was  compiled  and  executed 
successfully  by  accepting  itself  as  the  input. 


The  Trans lator-Wr it i no-System  (TWS)  [103  is  a  sophisticated  and 
powerful  technique  for  constructing  a  compiler.  The  use  of  this  TWS 
system  has  shortened  the  time  considerably  tor  generating  this 
PASCAL  compiler.  However*  one  difficulty  was  encountered  in 
adopting  the  MSP  formal  parsing  algorithm:  changes  in  syntax 
specifications   were   not  trivial  when  an  extension  was  added  to  the 
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lanquage.  Also  the  MSP  PASCAL  grammar  [Appendix  A]  was  not 
efficient  in  describing  the  syntax  for  READ  ana  WRITE  statements. 
Parsinct  of  the  READ/WRITE  and  other  extensions  was  achieved  by 
treating  these  as  exceptions  to  the  MSP  PASCAL  grammar.  However/ 
there  is  no  systematic  and  clean  way  to  accommodate  the  chanqes 
without  affecting  the  modularity  and  readability  of  the  compiler. 


The  PASCAL  language  is  becoming  more  and  more  popular;  several 
institutions  have  implemented  PASCAL  compilers  for  other  computers* 
including  CDC  6000  series/  PDP-11/  DEC  System  10/  IBM  360/370/  and 
UNIVAC  110P.  This  PASCAL  compiler  is  perhaps  the  first 
implementation  to  use  a  bottom-up  parsing  algorithm/  and  it  would  be 
desirable  that  a  comparison  between  this  compiler  and  other 
implementations  be  conducted  in  the  future. 
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APPENDIX  A  -  THE  PASCAL  BNF  GRAMMAR 

F  resented  in  this  appendix  is  the  PASCAL  BNF  grammar/  which  is 
MSP  of  deqree  (2/1*1*1)  parsable.  The  statistics  about  the  syntax 
tables/  nenerated  by  grammar  analyzer  with  this  BNF  grammar  as  its 
input/  are  given  in  Appendix  B . 


1  <PP0GRAM>  ::=  <PR06RAM  HEADING>  <B0DYP> 

2  <PR0GRAM>  ::=  <B0DYP> 

?  <BO0YP>  ::=  <B0DY>  . 

4  <PR0GRAM  HEADING>  ::=  <PR0GRAM  NAME>  /' 

b  <PR0GRAM  HEADING>  ::=  <PR0GRAM  NAME>  <PR0GRAM  PARAMETERS>  ; 

6  <PR0GRAM  NAME>  ::=  PROGRAM  <IDENTIFIER> 

7  <PR0GRAM  PARAMETERS>  ::=  <F0RMAL  HEAD>  <F0RMAL  PARAMETER>  ) 

i  <F0RMAL  HEAD>  ::=  ( 

•'  <F0RMAL  HfAD>  ::=  <F0RMAL  HEAD>  <F0RMAL  PARAMETER>  ; 


10  <F0RMAL  PARAMETER> 

11  <F0RMAL  PARAMETER> 
1?  <F0RMAL  PARAMETER> 
13  <F0RMAL  PARAMETER> 


=  <TYPE  DECLARATIONS 

=  VAR  <TYPE  DECLARATI0N> 

=  <FUNCTI0N  LIST>  <TYPE> 

-    <PR0CEDURE  LIST>  <1DENTIFIER> 


U  <FUNCTI0N  LIST>  ::=  <FUNCTI0N  LIST  HEAD>  <IDENTIFIER>  : 

15  <FUNCTI0N  LIST  HEAD>  ::=  FUNCTION 

16  <FUNCTI0N  LIST  HEAD>  ::=  <FUNCTI0N  LIST  HEAD>  <IDENTIFIER>  / 

17  <PR0CEDURE  LIST>  ::=  PROCEDURE 

18  <PR0CEDURE  LIST>  ::=  <PR0CEDURE  LIST>  <IDENTIFIER>  / 

U  <STATEMENT  LIST>  ::  =  <STATEMENT> 

20  <STATEMENT  LIST>  ::=  <STATEMENT  LIST;>  <STATEMENT> 

21  <STATEMENT  LIST/'>  ::=  <STATEMENT  LIST>  ; 

22  <STATEMENT>  ::=  <BASIC  STATEMENT> 
21  <STATEMENT>  ::  =  <IF  STATEMENT> 


24   <BASTC  STATEMENT>  ::=  <ASSIGNMENT  STATEMENT> 
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25  <RASIC  STATEMENTS 

26  <BAS1C  STATEMENT> 

27  <BASIC  STATEMENT> 
?.>  <BASIC  STATEMENT> 


3d 
31 
32 

3  3 

34 

J,  5 
36 
37 

38 


4  0 
41 
4^ 

45 

44 

45 

46 
47 
4F 


4Y 
50 


=  STRUCTURED  STATEMfcNT> 

=  <PROCEDURE  STATEMENT> 

=  <G0T0  STATEMENT> 

=  <LABEL  DEFINITION  <BASIC  STATEMENT> 


2<;   <LABFL  DFFINITION>  ::  =  <UNSI6NED  NUMBER> 


<IP  STATEMENT> 
<IF  STATEMENT> 
<IF  STATFMENT> 


=  <IF  CLAUSE>  <STATEMENT> 

=  <IF  CLAUSE>  <TRUE  PART>  <STATEMENT> 

=  <LABEL  DEFINITION>  <IF  STATEMENT> 


<IF  CLAUSE> 
<TRUE  PART> 


:=  IF  <EXPRESSION>  THEN 
:=  <BASIC  STATEMENT>  ELSE 


STRUCTURED  STATEMENT> 

<STRUCTURED  STATEMENT> 

<STRUCTURED  STATEMENT> 

<STRUCTURED  STATEMENT> 


=  <COMPOUND  STATEMENT> 
=  <CASE  STATEMENT> 
=  <REPETITIVE  STATEMENT> 
=  <WITH  STATEMENT> 


3(<   <COMPOUND  STATEMENT>  ::  =  BEGIN  STATEMENT  LIST>  END 


REPETITIVE  STATEMENT> 
REPETITIVE  STATEMENT> 
<REPETITIVE  STATEMENT> 


=  <WHILE  STATEMENT> 
=  <REPEAT  STATEMENT> 
-  <F0R  STATE KENT> 


<WHILE  STATEMENT>  ::=  <WHILE  CLAUSE>  DO  <STATEMENT> 

<WHILE  CLAUSE>  ::=  WHILE  <EXPRESSION> 

<REPEAT  STATEMENT>  ::=  <REPEAT  HEAD>  <STATEMtNT  LIST>  UNTIL 

<FXPRESSION> 

<REPEAT  HEAD>  ::=  REPEAT 

<FOR  STATEMENT>  ::=  FOR  <STEP  DEFINITION>  DO  <STATEMENT> 

<STEP  DEFINITION>  ::=  <VARIABLE  IDENTIFIER>  :=  <EXPRESSION> 

<ITERATION  CONTROL> 

<1TERATI0N  CONTROL>  ::  =  TO  <EXPRESSION> 
<ITERATION  CONTROL>  ::=  DOWNTO  <EXPRESSION> 


51   <CASE  STATEMENT>  ::=  <CASE  LIST>  <STATEMENT>  END 


52  <CASE  HEAD> 

53  <CASE  HEAD> 

54  <CASE  HEAD> 


=  CASE  <EXPRESSION>  OF 

=  <CASE  HEAD>  <CONSTANT>  , 

-    <CASE  LIST>  <STATEMENT>  ; 


55   <CASE  LIST>  ::=  <CASE  HEAD>  <CONSTANT> 
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56  PROCEDURE  STATEMENT>  ::=  <PROCEDURE  IDENTIPIER> 

57  <PROCEDURE  STATEMENT^  ::=  <PROC  ARG  HEA0>  <PARAMFTER  LIST>  ) 

56  <PROC  ARG  HfcAD>  ::=  <PROCEDURE  IDENTIFIER>  ( 

50  <PARAMFTFk  LIST>  ::=  <ACTUAL  PARAMETER> 

6G  <PARAMETER  LIST>  ::=  <PARAMETER  LIST,>  <ACTUAL  PARAMETER> 

61  <PARAI*ETER  LIST/>  ::=  <PARAHETER  LIST>  , 

6?  <ACTUAL  PARAMETER>  ::-  <EXPRESSION> 

6^  <ACTUAL  PARAMfcTER>  ::=  <PROCEDURE  IDENTIFIER> 

6A  <PROCEDURE  DECLARATION  ::=  <PROCEDURt  HfcADING>  <BODYPROC> 

65  <BODYPROC>  ::=  <BODY> 

66  <PROCEOURE  HEADING>  ::=  <PROC  NAKE>  ; 

67  <PROCEDURE  HEAD1NG>  ::=  <PROC  ARGS>  ; 

68  <PROC  ARGS>  ::=  <PROC  NAME>  <PROGRAM  PARAMETERS> 
*9  <PROC  NAME>  ::=  PROCEOURF  <IDENTIFIER> 

70  <FUNCTION  DECLARATIONS  ::=  <FNDCL>  <HODYPROC> 

71  <FNDCL>  ::=  <FUNCTION  HEADING>  <TYPE>  ; 

72  <FUNCTION  HEADING>  ::=  FUNCTION  <IDENTIFIER>  ; 

73  <FUNCTION  HEADING>  ::=  FUNCTION  <IDENTIFIER> 

<PROGRAM  PARAMETERS>  : 

7U  <GOTO  STATEMENT>  ::=  GOTO  <UNSIGNED  NUMEER> 


75  <BODY>  ::=  <LABEL  DECLARATION  PART>  <BODY?> 

76  <RODY>  : :=  <B0DY2> 

77  <LABFL  DECLARATION  PART>  ::  =  <LABEL  HEAD>  <UNSIGNED  NUMBER>  ; 

7b  <LABEL  HEAD>  ::  =  LABEL 

79  <LABEL  HEAD>  ::=  <LABEL  HEAD>  <UNSIGNED  NUNBER>  , 

80  <BGDY2>  ::=  <CONSTANT  DEFINITION  PART>  <B0DY3> 

81  <B0DY2>  :  :  =.  <B0DY3> 

82  <CONSTANT>  ::=  <CONSTANT  DEF>  <IDENTIFIER>  =  <CONSTANT  DEF>  ; 
8?  <CONSTANT  DEFINITION  PART>  ::=  <CONSTANT  DEF> 

84  <CONSTANT  DEF>  ::=  CONST  <IDENTIFIER>  =  <CONSTANT>  ; 
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*-5   <B0DY3>  ::=  <TYPE  DEFINITION  PART>  <BODY4> 
86   <EODY3>  ::=  <B0DY4> 

»7       <TYPF  DEFINITION  PART>  ::  =  TYPE  <TYPE  DEFINITION>  ; 
^   <TYPF  DEFINITION  PART>  ::  =  <TYPE  DEFINITION  PART> 

<TYPE  DEFINITION>  I 

89   <TYPE  DEFINITION>  ::=  <IDENTIFIER>  =  <TYPE> 


9  0 
91 
9? 
9? 

94 
9^ 
96 

97 
98 
09 


101 
10? 

103 

104 

105 

106 

107 

10h 

10v 
110 

111 
112 


<TYPE> 
<TYPE> 
<TYPE> 
<TYPF> 


=  <SIMPLE  TYPE> 

=  STRUCTURED  TYPE> 

=  3  <TYPE  IDENTIFIER> 

=  <SCALAR  TYPE> 


<STRUCTURED  TYPE> 
<STRUCTURED  TYPE> 
<STRUCTUPED  TYPE> 


-  <UNPACKED  STRUCTURED  TYPE> 

=  PACKED  <UNPACKED  STRUCTURED  TYPE> 

=  <FILE  TYPE> 


<UNPACKED  STRUCTURED  TYPE> 
<UNPACKED  STRUCTURED  TYPE> 
<UNPACKED  STRUCTURED  TYPE> 


=  <ARRAY  TYPE> 

=  <RECORD  TYPE> 

=  <SET  0F>  <SIMPLE  TYPE> 


100   <SET  0F>  : :=  SET  OF 


<SIMPLE  TYPO 
<SIMPLE  TYPE> 


=  <SUbRANGE  TYPE> 
=  <TYPE  IDENTIFIER> 


<SCALAR  TYPE> 
<SCALAR  HEAD> 


:=  <SCALAR  HEAD>  <IDENTIFIER  LIST>  ) 

:=  ( 

<SUBRANGE  TYPE>  ::=  <C0NSTANT>  ..  <C0NSTANT> 

<ARRAY  TYPE>  ::=  <ARRAY  HEAD>  <SIMPLF  TYPE  LIST>  J  <0F  TYPE> 

<ARRAY  HEAD>  ::=  ARRAY  C 

<0F  TYPE>  ::=  OF  <TYPF> 

<SIMPLE  TYPE  LIST>  ::  =  <SIMPLE  TYPE> 

<SIMPLE  TYPE  LIST>  ::=  <SIMPLE  TYPE  LIST>  ,  <SIMPLE  TYPE> 

<B0DY4>  ::=  <VARIABLE  DECLARATION>  <B0DY5> 
<B0DY4>  : :=  <B0DY5> 


113   <VARIABLk  DECLARATION>  ::=  <VARIABLE  DECLARATION  PART>  ; 

1H   <VARIABLE  DECLARATION  PART>  ::=  VAR  <TYPE  DECLARATION> 
115   <VARIABLE  DECLARATION  PART>  ::=  <VARIABLE  DECLARATION  ELEMENT> 

<TYPE  DECLARATION> 
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116  <VARIA6LF  DECLARATION  ELEMENT>  ::=  <VARIABLfc  DECLARATION  PART>  ; 

117  <TYPE  DECLARATION>  ::=  <NEW  TYPE  IDENTIFIERS>  <TYPE> 
11H  <NEW  TYPF  IDENTIFIERS>  ::=  <IDENTIFIER  LIST>  : 

11V  <IDENTIFIER  LIST>  ::=  <IDENTIFIER> 

120  <IDFNTIFIER  LIST>  ::=  <IDFNTIFIER  LIST  ELEMENT>  <IDENTIFIER> 

121  IDENTIFIER  LIST  ELEMENT>  ::=  <IDENTIFIER  LIST>  , 


122 
123 
124 

125 
126 

127 

12fa 

12Q 
130 


131 
132 

133 

134 

135 
136 
137 


<VARIABLE> 
<VARI  ABLE> 
<VARIABLE> 


=  <ENTIRE  VARIABLE> 

=  <COMPONENT  VARIABLE> 

=  <VARIABLE>  * 


<PODY5>  ::=  <PROC  DEF>  <B0DY6> 
<BODY5>  ::=  <B0DY6> 

<B0DY6>  ::=  <COMPOUND  STATEKENT> 

<PROC  DEF>  ::=  <PROC  DEF1NITI0NS> 

<PR0C  DEFINITIONS>  ::-  <PROCEDURE  OR  FUNCTION  DECLARATION>  ; 
<PROC  DEFINITIONS>  ::  =  <PROC  DEFINITIONS> 

<PROCEDURE  OR  FUNCTION  DECLARATION>  ; 

<PROCEDURE  OR  FUNCTION  DECLARATION>  ::=  <PROCEDURE  DECLARATION> 
<PROCEDURE  OR  FUNCTION  DECLARATION>  ::=  <FUNCTION  DECLARATION> 

<ENTIRE  VARIABLE>  ::=  <VARIABLE  IDENT1FIER> 

<VARIABLE  IDENTIFIER>  ::=  <IDENTIFIER> 

<COMPONENT  VARIABLE>  ::=  <INDEXED  VARIABLb> 
<COMPONENT  VAR1ABLE>  ::=  <FIELD  DESIGNATOR> 
<COMPONENT  VARIABLE>  ::=  <VARIABLE>  % 


13*   <VARIABLF  IDENTIFIER>  ::=  <ARRAY  VARIABLE>  <PARAMETER  LIST>  3 
139   <ARRAY  VARIABLE>  ::=  <VARIABLE  IDENTIFIER>  C 


140 
141 
142 
143 
144 
145 

146 
147 


<FACTOR> 
<FACTOR> 
<FACTOR> 
<FACTOR> 
<FACTOR> 
<F ACTOR> 


=  <VARIABLE> 

=  <UNSIGNED  CONSTANT> 

=  <FUNCTION  DESI6NAT0R> 

=  (  <EXPRESSION>  ) 

=  <SET> 

=   <FACTOR> 


<SET>  ::  =  C  <PARAMETER  LIST>  3 
<SET>  ::-  [  3 
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148 
149 
150 
151 
152 
153 

154 
155 
156 
157 
158 

159 
160 

161 
162 


163 
164 
165 
166 
167 
168 

169 
170 


171 
172 
173 

174 
175 
176 

177 
178 

179 
180 

181 

182 

183 


<TERM> 
<TERM> 
<TERM> 
<TERM> 
<TERM> 
<TERM> 

<SIMPLE 
<SIMPLE 
<SIMPLE 
<SIMPLE 
<SIMPLE 


<FACTOR> 

<TERM>  * 

<TERM> 

<TERM> 

<TERM> 

<TERM> 


<FACT0R> 
/  <FACT0R> 
DIV  <FACT0R> 
MOD  <FACTOR> 
ft  <FACTOR> 


<  S  I G  M 
<SIGN 


2> 

2> 


FXPRESSION> 
EXPRESSION 
EXPRESSION 
EXPRESSION> 
EXPRESSION> 

=  + 


=  <TERM> 

=  <SIMPLE  EXPRESSION>  ♦  <TERM> 
=  <SIMPLE  EXPRESSION>  -  <TERM> 
-  <SIMPLE  EXPRESSION>  !  <TERM> 
=  <SIGN  2>  <TERM> 


<EXPRESSION> 
<EXPRESSION> 


=  <SIMPLE 

=  <SIMPLE 

<SIMPLE 


EXPRESSION> 
EXPRESSION> 
EXPRESSION 


RELATIONAL  0PERATOR> 


RELATIONAL 
<RELATIONAL 
RELATIONAL 
RELATIONAL 
RELATIONAL 
RELATIONAL 


OPERATOR> 
OPERATOR> 
OPERATOR> 
OPERATOR> 
OPERATOR> 
()PERATOR> 


=  < 

=  > 

=  > 

=  < 


<ASSIGNMENT  STATEMENT>  ::=  <VARIABLE>  :=  <EXPRESSION> 
<ASSIGNMENT  STATEMENT>  ::  =  <FUNCTION  IDENTIFIER>  := 

<EXPRESSION> 


<UNSIGNED  CONSTANT> 
<UNSIGNED  CONSTANT> 
<UNSIGNED  CONSTANT> 


=  <UNSIGNED  NUMBER> 
=  <STRING> 
=  NIL 


<CONSTANT>  : 
<CONSTANT>  : 
<CONSTANT>  : 


=  <UNSIGNED  NUMBER> 

=  <SIGN>  <UNSIGNED  NUMBQR> 

=  <STRING> 


<SIGN> 
<SIGN> 


=  ♦ 


<FUNCTION  DESIGNATOR>  ::=  <FUNCTION  IDENTIFIbR> 

<FUNCTION  DESIGNATOR>  ::=  <FN  ARG  HEAD>  RARAMETER  LIST>  ) 

<FN  ARG  HEAD>  ::=  <FUNCTION  IOENTIFIER>  ( 

<VARIABLE  IDENTIFIER>  ::=  <VARIABLE>  .  <FIELD  IDENTIFIER> 

<RECORD  TYPE>  ::=  RECORD  <FIELD  LIST>  END 
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1K 
185 
1.W 

1F7 

1^ 

1*9 
190 
191 
19? 
19  6 


1  u  f 
197 

19* 

199 

2  on 

201 

2C2 

2  0  3 

2(  4 

2  05 


<  F  I E  L  D  L  I  ST> 

<  F  IELD  LI  ST> 

<  F  I  F  L  D  L  I  S  T  > 


=  <  F  I  XE  D  PART> 

=  <F  I  X  ED  PART>  ;  < VARIANT  PART> 

=  <VARIANT  PART> 


<  F  I  X  F  D  PART>  ::=  <  T  Y  P  F   DECLARATION> 

<FIXFD  PART>  ::=  <FlXtO  PART  L1ST>  <TYPE  DECLARATION 

<FIXED  PART  LIST>  ::=  <FIXED  PART>  /' 

< VARIANT  PART>  ::=  <LAPEL  LIST>  (  <FIELD  LIST>  ) 

<VA RIANT  HEAD>  ::=  CASE  <1DENTIFIER>  : 


<  V  A  R  I  A  N  T  PART  HEAD> 
< VARIANT  PART  HEAD> 
<VAF1ANT  HART  H  E  A  D  > 


=  <VARIANT  HEAD>  <TYPE  IDENTIFIER>  OF 
=  <VARIANT  PART  HEAD>  <CONSTANT>  , 
-    <LABEL  LIST>  (  <FIELD  LIST>  )  ; 


195   < LABEL  LIST>  ::=  < VARIANT  PART  HEAD>  <CONSTANT> 


<F  II  F  TYi  F> 

<  F  I  L  E  T  Y  P  E  > 

<  f   ILL  TYPt  1 > 
<F  ILE  TYf  F  1> 


=  PACKED  <F  ILE  TYPE1> 
=  <  F  I  LE  TYPE1> 

:  =  NONSTANDARD  <F1LE  TYPE2> 
:=  <F I LE  TYPE2> 


<FILE  TYPF?>  ::=  PINARY  <  F  I  LE  TYPE3> 

<  F I L  F  T  Y  P  E  2  >  ::-  <  F  I  LE  T  Y  P  E  3  > 

<  F I L  E  TYPE3>  ::=  FILE  <0F  TYPE> 

<WITH  STATFMENT>  ::=  WITH  <RECORD  VARIABLE  LIST>  DO  <STATEMENT> 

<RFCORD  VARIABLE  LIST>  ::=     <VARIABLE> 

<RECORD  VARIABLE  LIST>  ::=  <RECORD  VARIABLE  LIST*>  <VARIABLE> 


2  ( j  *   <  R  t  C  0  R  D  VARIABLE  L  I  S  T  ,  > 


=  <RECORD  VARIABLE  LIST>  / 
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APPENDIX  B  -  STATISTICS  FOR  SYNTAX  TABLES 


Due  to  the  size  of  the  syntax  tables  generated  by  the  grammar 
ANALYZFR*  only  the  statistics  for  those  tables  are  listed  below.  Also 
included  are  those  data  from  the  XCOW  compiler  as  a  comparison/  where 
XCOri  is  the  se  I  f -compi  I  ing  compiler  for  XPL.  The  documentation  for 
these  syntax  tables  can  be  found  in  section  9 .5  of  "A  Compiler 
(.er.erator"  [13. 


PASCAL  XCOM 

a************************************************** 


U    o  f  B  N  F  g  r  a  m  m  a  r  2  06 

<•'  of  terminal  66 

»  of  nonterminal  180 

C1  (bit)  180*134 

C1TRIPLE  (24  bits)  589 

PRTtf  (32  bits)  206 

PRDTB(8bits)  207 

HDTF  ({■     bits)  207 

PRLENGTH  (r  hits)  207 

C0^TEXT_CASE  (8  bits)  207 

LEFT_C0NTEXT  ( *  bits)  38 

LEFT_INDEX(8bits)  115 

C0NTFXT_TRIPLE  (24  bits)  14 

TR IPLE_INDEX  (8  bits)  115 

PR  INDEX  <x  bits)  181 


109 

42 

91 

91*86 

203 

109 

110 

110 

110 

110 

2 

50 

0 

50 

92 


*************************************************** 
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AP^tNDIX  C  -  SPECIFICATIONS  FOR  THE  SEMANTIC  STACK 


The  semantic  stack  is  under  the  control  of  the  SYNTHESI 
subroutine  which  pushes  or  pops  the  semantic  information  associated 
with  a  nonterminal  node  in  the  syntax  tree.  The  function  of  the 
semantic  stack  is  to  commute  the  information  between  code  generation 
routines.  Each  entry  in  the  semantic  stack  consists  of  two  words. 
The  first  word  is  further  divided  into  three  subfields:  TYPE,  FLAG  and 
LlbGTM.  The  subfield  LENGTH  specifies  number  of  the  bits  allocated 
for  <i  particular  operand.  The  subfield  TYPE  is  used  to  indicate  the 
elementary  type  of  an  operand  and  has  the  following  categories 

1  -  real 

2  -  integer 

3  -  boolean 
U  -  set 
5  -  character 
(:  -  s  t  r  i  m  constant 


The  second  word  of  an  entry  is  used  as  a  modifier  whose 
interpretation  depends  on  the  FLAG  of  the  first  word.  The  FLAG  and 
the  interpretation  of  the  modifier  are 


FLAG 


MODIF IERCsecond  word) 


1  -  immediate  constant 

2  -  I  a rqe  const  ant 

(great  than  16  bits) 

3  -  identifier 

4  -  temporary  value 

5  -  address  pointer 

in  register 

6  -  address  pointer  in 

temporary  location 

7  -  value  in  register 

?.    -    byte  address  pointer 
in  a  register  pair 


its  value  (16  bits) 

pointer  into  constant  table 

pointer  into  symbol  table 
relative  stack  offset 
register  #  of  pointer 

relative  stack  offset 

register  tt    of  value 

even  register  #  of  pointer 


The  relative  stack  offset  is  the  offset  relative  to  register  3 
which  is  the  local  data  pointer.  The  TYPE,  FLAG  and  LENGTH  subfield; 
are  packed  into  one  word,  where  TYPE  and  FLAG  subfields  occupy  5  bit: 
each,  and  the  LENGTH  subfield  occupies  6  bits.  New  items  can  be  aadei 
to  TYPE  and  FLAG  for  design  modification  or  for  code  optimization. 
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APFTNDIX  D  -  PASCAL  RUNTIME  PACKAGE  ANO  EXTERNAL  PROCEDURES 

There  is  a  library  for  PASCAL  routines  which  includes  the  runtime 
packaoe  and  external  procedures.  The  following  procedures  are  some  of 
the  basic  routines/  and  most  of  them  are  defined  in  PASCAL  user  manual 
C53.  However/  the  members  of  the  library  are  growing  continuously  and 
not  all  of  them  are  listed  here. 


D  .1  .   THE  PROCEDURE  WRITE 

The  procedure  WRITE  can  be  used  to  access  sequential  or  random 
files.   The  syntax  of  the  wRITE  statement  for  sequential  files  is 

WKITF  file-name  (parameter  lists); 
wh^re   the   file   is   defaulted  to  OUTPUT  if  the  tile-name  is  omitted. 
For  rondom  files/  the  syntax  of  the  WRITE  statement  is 

WKITT  file-name  Cpos i t i on-i ndex]  (buffer). 

The  procedure  WRITE  was  implemented  as  a  group  of  routines  instead  of 
as  a  single  routine  with  many  entry  points.  With  this  approach*  only 
thr  routines  required  by  a  user's  program  will  be  loaded  into  the  core 
memory  by  the  link  loader.  Therefore/  this  PASCAL  compiler  generates 
a  procedure  call  to  a  selected  runtime  routine/  depending  on  the  type 
of  the  file  (random  or  sequential/  packed  or  nonpacked)  and  on  the 
tyfe  of  the  parameter. 

In  this  implementation/  the  end  of  line  must  be  explicitly 
specified  by  a  predefined  character  EOL  as  one  of  the  parameters  to 
the  procedure  WRITE.  A  keyword  PAGE  can  also  be  used  as  an  argument 
to  the  procedure  WRITE.  The  routine  invokeo  by  the  keyword  PAGE  will 
send  out  the  last  buffer  if  it  is  not  empty;  it  then  sends  out  a 
control  character  *1'  which  means  skip  to  the  top  of  a  new  paqe  for 
thp  line  printer.  For  examp le : (assume  the  file  line_printer  is 
assigned  to  the  line  printer) 

WRITt  line_printer  (PAGE/'  a  new  page  '/EOL) 
would  print  the  message  'a  new  page'  at  the  top  of  a  new  page. 


D.2 


THE  PROCEDURE  READ 


The   syntax  for  the  READ  statement  is  the  same  as  for  that  of  the 

WRITE   statement.   However/   the   default  file  is  INPUT  for  sequential 

read.   The  procedure  READ  was  also  implemented  as  a  group  of  routines/ 
for  the  same  reason  as  stated  above. 


There  is  a  one-character  look  ahead  for  reaOing  from 
non-interactive  devices/  yet  there  is  no  look  ahead  for  interactive 
devices  such  as  CRT  terminals.  An  end-of-file  flag  is  set  for  the 
input  file  upon  readinj  in  the  last  character/  and  the  end-of-file 
condition  can  be  checked  by  calling  the  standard  function  EOF.  An 
input  request  to  the  file  with  the  end-of-file  flay  set  will  cause  the 
pro oram   to  be  terminated  after  sending  the  error  message  "  ERROR:  END 
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OF  FILF  ".  In  addition  to  the  attributes  of  the  input  file/  the 
response  of  the  READ  routines  depends  on  the  type  of  the  parameters. 
For  example/  if  the  parameter  is  one  of  the  type  integer/  the  input 
stream  will  be  seached  until  a  number  is  found  and  converted  into 
internal  representation.   Therefore/  if  the  input  stream  is 

A  STRING  TO  BF  NEGLECTFD   +10/  20/  ANOTHER  STRING   -30 

then   the   statement  RE  AD  ( i / j  /  k )  /  where  i/j  and  k  are  of  type  inteqer/ 

will   assign   10   to  i/   20   to   j   and   -30  to  k.   If  end-of-file  is 

encountered   before  a  number  is  found/  the  executation  of  the  proqram 

will  he  terminated  after  sending  the  error  message  "  ERROR:  END  OF 
FILF.  " . 


D.3.   PROCFDURb  RESET  (fi  le_name) 

The  actual  parameter  file_name  is  either  standard  files  or  user 
defined  files.  The  procedure  RESET  will  check  and  send  out  the  last 
buffer  it  is  not  empty/  and  will  call  R  E  X  ( #  7  )  service  routine  to  write 
end-of-file  mark  on  1/0  device  specified  by  the  file_name.  The 
end-of-file  tlaa  is  cleared/  if  the  file  is  not  empty/  i.e. 
tf'F(file_name)  becomes  false.  Otherwise/  the  end-of-file  flag  is  set/ 
and  F OF ( f i  le_name)  becomes  true.  RESET  then  calls  another  RFX(*2) 
service  routine  to  reset  the  tile  position  to  its  beginning/  and  the 
file  is  ready  for  input. 


D.4.  PROCEDURE  REWRITECfile  name) 


The  proceure  REWRITE  causes  the  file  to  be 
end-of-file  mark  is  put  at  the  beginning  of  the  file, 
is  set/  and  EOFCfile  name)  becomes  true. 


rewound/  and  the 
The  end-of -f  i le 


D.3 


FUNC I TI0N  EOF  (file  name) 


The   function  EOF  tests  the  end-of-file  flag/  and  it  returns  true 
if  the  flao  is  set. 


D.6 


FUNCTION  0RD  (x) 


The  result  is  the  ordinal  number  of  type  integer  of  the  value  x 
in  the  set  oefined  by  the  type  of  x.  0RD  is  handled  at  compile  time 
by  changing  the  TYPF  subfield  of  the  entry  (in  the  semantic  stack) 
which  specifies  the  attributes  of  the  parameter  x.  Therefore/  no 
subroutine  call  is  generated  by  compiling  0RD. 
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0.7 


FUNCTION  CHR(x) 


The  parameter  x  must  be  of  type  integer  and  the  result  is  the 
character  whose  ordinal  number  is  x.  The  CHR  function  is  compiled  in 
the  same  way  as  the  ORD  function. 

D.J-.   DYNAMIC  SPACE  ALLOCATION  PROCEDURES  FOR  PASCAL 

The  procedure  NFW(P)  allocates  a  new  variable  V  of  type  T  (to 
which  P  is  bounded)  and  assians  the  pointer  V  to  the  pointer  variable 
P.  The  procedure  DISPOSE(P)  is  used  to  return  storage  to  the  free 
pool.  The  dynamic  space  allocation  procedures  are  cooed  by  D.  W. 
JOKES  and  are  in  the  debugging  stage  at  the  time  of  preparing  this 
\.  a\  er  . 

The  NEW  procedure  allocates  a  new  block  of  storage  each  time  it 
is  called*  and  points  its  parameter  at  that  block.  The  block  is 
allocated  large  enouoh  to  hold  the  type  associated  with  the  pointer 
parameter*  and  it  is  initialized  to  all  zero.  NEW  will  optionally 
return  NIL  instead  of  aborting  if  it  is  unable  to  allocate  new 
storage;  this  can  be  used  as  a  signal  to  the  user  program  to  garbage 
collect  its  own  data  structures. 

The  FREE  procedure  returns  a  block  of  storage  to  the  free  space 
pool  so  that  it  may  be  reallocated  by  NEW  at  some  later  time.  FREE 
will  always  set  its  parameter  to  NIL  on  completion*  and  it  will  abort 
if  it  detects  that  it  is  given  a  reference  to  already  free  space. 

When  NEW  or  FREE  aborts*  it  attempts  to  return  appropriate 
information.   The  followinq  aborts  are  due  to  calls  to  NEW: 

A FORT  (NEW  MAP  #high)   -  Free  space  pool  entirely  used  up* 

option  POOLMEM  not  selected. 

ABORT  (NEW  ALO  #cccc)   -  Allocate  memory  failed. 

ABORT  (NEW  MEM  flsize)   -  No  free  space  large  enough* 

option  POOLSIZE  not  selected. 

ABORT  (NEW  INI  tfhigh)   -  On  first  call  tc  NEW*  unable  to  startup* 

insufficient  unallocated  memory. 

The  following  aborts  are  due  to  calls  to  FREE: 


/SHORT  (FPF  ERR  #pntr)   -  The  space  to  be  freea  was  either 

already  free  or  not  in  the  pool. 
ABORT  (FRE  DAM  #pntr)   -  Freed  pages  could  not  be  deallocated. 

In   these   abort   messages*   the  hex  values  returned  are  not  the 
address  at  which  the  error  occured.   Instead*  they  are  as  follows: 


F  a  g  e   6  ? 


tfKiqh  -  the  map  Limit  or  current  high  address  known  by  NEW. 

*cccr  -  the  condition  codes  returned  by  RFX  service  #29  or  #2A 

ftsize  -  the  size  of  the  offending  request. 

"pntr  -  the  address  of  the  invalid  region  being  returned. 


D.9.   FUNCTION  ISHfT(xzCOunter) 

The  parameter  x  must  be  of  type  integer*  and  the  counter  must  be 
an  expression  evaluated  to  an  integer  value.  Let  c=ABS ( count er )  MOD 
16*  then  x  is  shift  left  logically  c  bit  positions  if  counter>=0*  or  x 
is  shift  riqht  logically  c  bit  positions  if  counter<0. 


P.1C.   COMMUNICATION  WITH  OPERATING  SYSTEM 


MAX  IV  operating  system  supplies  a  set  of  executive  service 
as   REX   services-   RFX   services   are   basically   reentran 


The 
re  f  e  r ed 

sut- routines  located  in  the  nucleus  of  the  operating  system*  and  may  b 
c^llej  by  executing  a  machine  instruction  REX.  The  arguments  betwee 
RFX  services  and  user  program  are  passed  and  returned  in  genera 
registers   whenever   possible*   and*   because   of 


this   scheme*  it  i 


registers  wnenever  possible*  ana*  Decause  ot  tnis  scneme*  u  l 
possible  to  specify  a  predefined  PASCAL  procedure  REX  whose  parameter 
are  the  imace  of  15  reqisters.  In  order  to  make  the  REX  procedur 
callable*  a  new  type  "word"  is  created  for  describing  the  type  o 
reqisters.  The  type  "word"  instructs  the  compiler  to  skip  the  typ 
checking*  and  the  RFX  is  defined  as: 

EXTERNAL  PROCEDURE  REX  (register:  ARRAYC1..15]  of  word). 

The  REX  procedure  is  equivalent  to  a  very  powerful  set  of  library 
procedures;  but*  at  the  same  time*  it  brakes  the  rule  of  strong  type 
checkinq  in  PASCAL.  A  better  long-term  solution  is  to  expand  the 
PASCAL  library  such  that  each  REX  service  corresponds  to  a  unique 
external  procedure. 


D.11.   PROCEDURE  FASSIGN 

The  procedure  FASSIGN  can  be  implemented  by  calling  the  procedure 
REX  (D.10);  however*  it  is  included  as  one  of  the  predefined 
procedures.  The  FXTERNAL  PROCEDURE  FASSIGN  allows  the  user  to  assijn 
thf  logical  files  (defined  by  the  operatinq  system)  to  the 
user-defined  files  at  run  time.  For  example*  F ASS  I GN (OUTPUT* ■ LPP ■ ) 
would  cause  the  logical  file  LPP  (line  printer)  to  be  assigned  to  the 
standard  file  OUTPUT. 
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APPENDIX  E 


-  MACROS  FOR  PREPARING  ASSEMBLY  SUBROUTINE 
AS  EXTERNAL  PROCEDURE 


The  extension  of  external  procedure  provides  the  programmer  with 
the  flexibility  to  program  his  subroutines  in  assembly  language. 
However^  in  order  to  make  the  subroutine  callable  and  to  maintain  the 
reentrant  properity/  the  receiving  sequence/  return  sequence/ 
parameter  passing  mechanism/  and  local  variable  allocation  for  the 
assembly  proqram  must  be  compatible  with  the  code  generated  by  the 
PASCAL  compiler.  A  set  of  assembly  macros  are  provided  to  help  users 
so  that  they  will  not  be  bothered  by  the  unnecessary  detail  of 
implementation. 

Reaisters  1/2  and  3  are  reserved/  and  they  cannot  be  used  without 
storino  and  restoring.  Except  for  REX  calls/  registers  1/2  and  3  are 
not  recommanded  to  be  used.  The  relative  address  appearing  in  the 
following  macro  definitions  is  defined  as  the  offset  relative  to  the 
local  data  pointer  register.  In  general/  the  format  of  a  macro  call 
is  to  place  its  name  in  the  instruction  field  and  followed  it  by 
optional  arguments. 

F  .1  .  PROC/x 

Macro  PPOC  inserts  the  receiving  sequence/  and  the  argument  x  is 
the  name  of  the  subroutine.  It  also  defines  BASE  (BASE=3  and  register 
3  is  used  as  local  data  pointer)  as  the  symbolic  name  for  local  data 
pointer  register. 

E.2.  VAR/x 

Macro  VAR  allocates  the  space  for  variable  x/  which  is  the 
parameter  passed  to  the  subroutine  by  reference.  The  argument  x  is 
then  defined  as  the  relative  address  of  the  location  which  holds  the 
address  of  variable  x  passed  by  the  calling  sequence. 


F.3.  VAL/X/y 


Macro   VAL   allocates   the   space   for   varable   x/   which  is  the 
parameter   passed   to  the  subroutine  by  value.   The  second  argument  y/ 


which   is   op t  i  ona I 
(numbe  r   of  words ) . 
the   code   to   copy 
argument   x   is  then 
of  variable  x . 


and  has  default  value  1/  indicates  the  size  of  x 
If  y  is  greater  than  1/  the  macro  VAL  will  insert 
the  structure  of  x  into  the  local  stack.  The 
defined  as  the  relative  address  of  the  first  word 
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E  .U .  RETURN/x 

Macro   RETURN   inserts   the   return  sequences.  The  argument  x  is 

optional   and   is   used   for   function  return  only.  If  x  presents*  it 

points   to  the  register  which  contains  the  value  to  be  returned  by  the 
f un  ct  ion. 

F  .5  .  TEMP/X/y 

facro  TEMP  is  used  to  allocate  space  for  local  variables  x.  The 
amument  y/  which  is  optional  and  has  default  value  1/  specifies  the 
size  (#  of  words)  of  the  local  variable  x.  The  macro  TEMP/  if  any/ 
must  be  placed  after  the  macro  VAL  and  VAR. 

E.6.  EXAMPLE 

A  simple  subroutine  is  given  as  an  example  for  clarity.  Assume 
that  a  routine*  which  assigns  the  sum  of  three  integer  variables  into 
another  variable/  is  needed.  First/  the  subroutine  is  declared  in  the 
main  program  as 

EXTERNAL  PROCEDURTE  ADD (VAR  SUM:INTE&ER; 

A/B/C  :INTEGER)/* 

The  subroutine  can  then  be  prepared  as  the  following: 


INS     MSI/PMAC 
PROC/ADD 


insert  the  file  of  macro  definitions 
receiving  sequence 


VAR /SUM 
VAL/A 
VAL/B 
VAL/C 


called  by  reference 
called  by  va lue 


LDM/1Q/BASE  A 

ADM/10/BASfc  P 

A0M/10/BASE  C 

STM*/10/BASE  SUM 


load  A  into  register  10 

add  B  to  regi  ster  10 

add  C  to  regi  ster  10 

store  A+B+C  indirectly  into  SUM 


PFTURN 
END 


return  sequence 


Page   65 


APPENDIX  F  -  REGISTER  ALLOCATION 


The   allocation  scheme  discused  below  is   based  on  the  allocation 
scheme  proposed  by  Douglas  Jones  and  A.  B.  Bask  in. 


Register  assionments: 


Register// 


Use 


Global  data  pointer  (display  base  pointer) 

Transfer  vector  pointer 

Local  data  pointer  (link  block  pointer) 


♦Scratch  indexing*  addressing/  and  base  registers 

* 


8 
9 
10 
11 
12 
13 
14 
15 


**        ** 

*  *Destroyed  by  subroutine  linkage 

*  * 

*  ** 

*Accumul ators 

* 

* 

** 


The  global  data  pointer  points  to  the  base  of  the  data  area.  The 
first  15  locations*  starting  at  the  address  pointed  to  by  the  global 
data  pointer*  serve  as  the  15  display  pointers  for  the  15  levels  of 
the  compile  time  nesting.  Variables  declared  at  the  outermost  level 
are  referenced  as  displacements  from  R1 .  In  addition  to  variables 
declared  at  this  outer  most  level*  there  may  be  at  most  15  more  levels 
of  compile  time  nesting. 

The  transfer  vector  pointer  points  to  a  vector  of  up  to  128 
entries*  each  entry  of  which  is  the  address  of  a  predefined  function. 
All  predefined  functions  are  referenced  by  their  predefined  index  in 
the  transfer  vector.  The  transfer  of  control  to  a  predefined  function 
is  accomplished  by  using  the  branch  and  link  inaexed  through  a  table 
instruction.  This  allows  an  absolute  minimum  of  linkage  overhead  for 
heavily  used  standard  functions. 


The  local  data  pointer  is  used  to  access  the  currently  active 
local  data  block.  This  block  contains  the  save  area  for  subroutine 
linkage*  and  the  local  variables  for  the  currently  active  program 
block  . 
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Reaisters  4-7  are  used  as  needed  for  addressing*  and  are  not 
normally  saved  as  a  part  of  subroutine  linkage.  These  registers  may 
be  used  by  predefined  functions*  and  their  contents  must  thus  be  saved 
prior  to  call  if  necessary. 


Fieoisters   8-15   serve   as  accumulators.   R8-R11  are  destroyed  by 
subroutine  linkage.   Registers  12-15  are  never  destroyed. 
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APPENDIX  6  -  SUBROUTINE  LINKAGE 


Two   basic  forms  of  subroutine  Linkage  are  proposed.   These  forms 

are   tailored   to  the  needs  of  normal  internal  subroutines  and  special 

predefined   routines.  Each   method   of   linkage   will  be  discussed  in 
detail  be  I  ow  . 


6.1.  INTERNAL  SUBROUTINE  LINKAGE 


Reqisters  R8-R10  play  a  special  role  in  internal  linkage.  These 
recisters  are  destroyed  during  linkage  and  are  not  restored.  The  use 
of  each  register  is  outlined  below: 


Regi  st er 


Use 


R8 
R<? 

P10 


contains  the  return  address 
contains  the  old  display 
for  the  destination  level 
contains  the  old  local  data  pointer 


The  actions  involved  in  internal  linkage  are  completely  defined 
by  the  code  to  be  generated  for  subroutine  call/  subroutine  entry/ 
subroutine  return/  and  exit.  The  functions  are  handled  in  the  same 
manner/  except  that  code  to  return  the  result  of  the  function  is 
generated  prior  to  the  code  to  return. 

Subrout  ine  call: 


TRR/10/3 
ADI/3    TCP 
BLT/I 


save  the  old  local  data  pointer 
construct  new  local  data  pointer 
branch  to  the  subroutine 


Recieving  sequence: 


LDS/9/  level 

STS/3/lvel 

SFX/8/3 


save  old  display  for  this  level 

set  new  display  entry 

save  accumulators  and  link  block 


Return  sequence : 
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LF  X,8,3 

TRR/3/10 

S  r$/<//  leve  I 

RRX/f 


restore  link  block  and  accumulators 

restore  old  local  data  pointer 

restore  old  display  pointer 
return 


Exit  sequence : 

LDS/3/ I evel 

B  R  U  »  0 


load  display  for  destination  level 
the  actual  branc  h 


where  1  is  the  index  of  the  subroutine  in  the  ransfer  vector  and 
TOE  is  a  compile  time  variable  containing  the  current  maximum  offset 
from  the  local  data  pointer.  Level  is  the  compile  time  static  nesting 
level  . 


&.?.  PREDEFINED  SUBROUTINES 


The  linkage  conventions  for  predefined  subroutines  are  quite 
simple.  Each  predefined  function  is  given  a  dedicated  location  in  the 
transfer  vector/  and  is  referenced  by  a  BLT  instruction.  Only 
reoisters  which  are  modified  by  the  routine  are  saved  and  restored. 
The  minimum  convention  consists  of  a  BLT  and  a  BRX  for  call  and 
return/  respectively. 
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